Re: Defense in depth: LSM *modules*, not a static interface

[Al Viro]

On Tue, Oct 30, 2007 at 03:14:33PM +0800, Cliffe wrote:
> Defense in depth has long been recognised as an important secure design 
> principle. Security is best achieved using a layered approach.
 
"Layered approach" is not a magic incantation to excuse any bit of snake
oil.  Homeopathic remedies might not harm (pure water is pure water),
but that's not an excuse for quackery.  And frankly, most of the
"security improvement" crowd sound exactly like woo-peddlers.
-
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] nfs: readv/writev with O_DIRECT fails on 2.6.24-rc1

[Gurudas Pai]

Trond Myklebust wrote:


On Mon, 2007-10-29 at 13:00 +0530, gurudas pai wrote:

Hi,

While running olt kit on 2.6.24-rc1 over nfs , Oracle reported I/O 
errors. I debugged little more and found that readv/writev are failing 
with O_DIRECT on nfs ( netapp's filer).


I am able to re-produce same error using ltp/diotest5.

./diotest5  -f /storage/nas/testfile -v 5

diotest05 1953719669  FAIL  :  readv failed: Invalid argument
diotest05 1953719670  FAIL  :  Read with Direct IO, Write without
diotest05 1953719671  FAIL  :  writev failed: Invalid argument
diotest05 1953719672  FAIL  :  Write with Direct IO, Read without
diotest05 1953719673  FAIL  :  writev failed: Invalid argument
diotest05 1953719674  FAIL  :  Read, Write with Direct IO
diotest050  INFO  :  3/3 testblocks failed

 >strace -e readv,writev ./diotest5  -f /storage/nas/testfile -v 5
writev(3, [{"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
4096}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
4096}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
4096}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
4096}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
4096}], 5) = 20480

readv(4, 0x8051000, 5)  = -1 EINVAL (Invalid argument)
diotest05 1953719669  FAIL  :  readv failed: Invalid argument
diotest05 1953719670  FAIL  :  Read with Direct IO, Write without
writev(3, [{"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
4096}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
4096}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
4096}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
4096}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
4096}], 5) = -1 EINVAL(Invalid argument)

diotest05 1953719671  FAIL  :  writev failed: Invalid argument
diotest05 1953719672  FAIL  :  Write with Direct IO, Read without
writev(3, [{"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
4096}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
4096}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
4096}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
4096}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
4096}], 5) = -1 EINVAL(Invalid argument)

diotest05 1953719673  FAIL  :  writev failed: Invalid argument
diotest05 1953719674  FAIL  :  Read, Write with Direct IO
diotest050  INFO  :  3/3 testblocks failed
Process 4749 detached


mount options:
rw,bg,nointr,hard,timeo=600,wsize=32768,rsize=32768,nfsvers=3,tcp,actimeo=0


Please let me know if I have to try test/debug patch.


Nobody has yet added support for nvec>1.



Tried with old kernel 2.6.18-8 (RHEL5), test passed with nvec=5.

>strace -fff -e readv,writev,open  ./diotest5 -f /storage/nas/testfile -v 5
open("/etc/ld.so.cache", O_RDONLY)  = 3
open("/lib/libc.so.6", O_RDONLY)= 3
open("/storage/nas/ca-ostest184.us.oracle.com/testfile", 
O_RDONLY|O_CREAT|O_DIRECT, 0666) = 3

open("/storage/nas/testfile", O_WRONLY|O_CREAT, 0666) = 3
open("/storage/nas//testfile", O_RDONLY|O_CREAT|O_DIRECT|O_LARGEFILE, 
0666) = 4
writev(3, [{"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
4096}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
4096}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
4096}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
4096}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
4096}], 5) = 20480
readv(4, [{"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
4096}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
4096}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
4096}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
4096}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
4096}], 5) = 20480
writev(3, [{"\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1"..., 
4096}, {"\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1"..., 
4096}, {"\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1"..., 
4096}, {"\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1"..., 
4096}, {"\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1"..., 
4096}], 5) = 20480
readv(4, [{"\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1"..., 
4096}, {"\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1"..., 
4096}, {"\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1"..., 
4096}, {"\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1"..., 
4096}, {"\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1"..., 
4096}], 5) = 20480
writev(3, [{"\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2"..., 
4096}, {"\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2"..., 
4096}, {"\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2"..., 
4096}, {"\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2\2"..., 
4096}, 

Re: [PATCH 1/5] update boot spec to 2.07

[rae l]

On 10/3/07, Rusty Russell <[EMAIL PROTECTED]> wrote:
> Proposed updates for version 2.07 of the boot protocol.  This includes:
>
...
> Signed-off-by: Jeremy Fitzhardinge < [EMAIL PROTECTED]>
> Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
> Cc: "Eric W. Biederman" < [EMAIL PROTECTED]>
> Cc: H. Peter Anvin <[EMAIL PROTECTED]>
> Cc: Vivek Goyal <[EMAIL PROTECTED] >
>
> ---
>  Documentation/i386/boot.txt|   34
Sugguestion is you also add an entry to the header of the file
(Documentation/i386/boot.txt):

something like this:

diff --git a/Documentation/i386/boot.txt b/Documentation/i386/boot.txt
index fc49b79..645bbd7 100644
--- a/Documentation/i386/boot.txt
+++ b/Documentation/i386/boot.txt
@@ -42,6 +42,9 @@ Protocol 2.05:(Kernel 2.6.20) Make protected mode
kernel relocatable.
 Protocol 2.06: (Kernel 2.6.22) Added a field that contains the size of
the boot command line

+Protocol 2.07: (Kernel 2.6.23) Added two fields hardware_subarch and
+   hardware_subarch_data to describe the paravirtualized
+   environment.

  MEMORY LAYOUT

-- 
Denis Cheng
Linux Application Developer

"One of my most productive days was throwing away 1000 lines of code."
 - Ken Thompson.
-
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/

Defense in depth: LSM *modules*, not a static interface

[Cliffe]

Defense in depth has long been recognised as an important secure design 
principle. Security is best achieved using a layered approach.


On a single system it makes sense to have a layered approach such as:

Standard DAC (where users are in control of permissions)
Some form of user-based non-DAC (where admins can specify what users can 
specifically do) such as SELinux or SMACK

System-wide firewall (netfilter)
Some form of sandboxes/namespace isolation (chroot, jails...)
General application confinement such as DTE (SELinux), or Capability 
lists (AppArmor, systrace ...)
Application network confinement - firewall to confine individual apps 
(maybe included in the above)

IDS or IPS
Malware scanner
Posix Capabilities
Pax/RaceGuard
...[insert innovation here]...

And while I acknowledge that many of these layers are currently buried 
within the kernel (netfilter...) they are security layers which in many 
cases would probably make sense as stackable security modules.


Making the interface static forces mammoth solutions which then must 
attempt to solve all of the above in one ls*m*. What happened to 
dividing tasks into easy to manage chunks?


Regards,

Z. Cliffe Schreuders
BSc Comp Sci (Hons) & Int Comp
PhD Candidate, Casual Tutor
School of IT
Murdoch University

-
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: [stable] 2.6.23 regression: top displaying 9999% CPU usage

[Balbir Singh]

Christian Borntraeger wrote:
> Am Montag, 29. Oktober 2007 schrieb Balbir Singh:
>> We'll also need this additional patch (untested), but in the long run
>> I think the approach needs to be
>>
>> 1. Update stime and utime at the time of context switching -- keep it
>>in sync with p->sum_exec_runtime
>> 2. Keep track of system/user context at system call entry points
> 
> This is similar to what s390 and ppc64 do when CONFIG_VIRT_CPU_ACCOUNTING is 
> set. Whenever you do a patch, please make sure to not break the already 
> precise values for utime and stime on s390 and ppc. Feel free to CC me 
> whenever you have a patch for this.
> 

Yes, true. I'll cc everyone on this list and send out the patch as RFC.
Much of this code will be architecture specific and as you rightly
pointed out, needs to happen under !CONFIG_VIRT_CPU_ACCOUNTING

> Christian


-- 
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
-
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 09/10] SLUB: Do our own locking via slab_lock and slab_unlock.

[Nick Piggin]

On Sunday 28 October 2007 14:32, Christoph Lameter wrote:
> Too many troubles with the bitlocks and we really do not need
> to do any bitops. Bitops do not effectively retrieve the old
> value which we want. So use a cmpxchg instead on the arches
> that allow it.
>
> Instead of modifying the page->flags with fake atomic operations
> we pass the page state as a parameter to functions. No function uses
> the slab state if the page lock is held. Function must wait until the
> lock is cleared. Thus we can defer the update of page->flags until slab
> processing is complete. The "unlock" operation is then simply updating
> page->flags.

Is this actually a speedup on any architecture to roll your own locking
rather than using bit spinlock?

I am not exactly convinced that smp_wmb() is a good idea to have in your
unlock, rather than the normally required smp_mb() that every other open
coded lock in the kernel is using today. If you comment every code path
where a load leaking out of the critical section would not be a problem,
then OK it may be correct, but I still don't think it is worth the
maintenance overhead.

>
> Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
>
>
> ---
>  mm/slub.c |  324
> +++--- 1 file
> changed, 187 insertions(+), 137 deletions(-)
>
> Index: linux-2.6/mm/slub.c
> ===
> --- linux-2.6.orig/mm/slub.c  2007-10-27 07:56:03.0 -0700
> +++ linux-2.6/mm/slub.c   2007-10-27 07:56:52.0 -0700
> @@ -101,6 +101,7 @@
>   */
>
>  #define FROZEN (1 << PG_active)
> +#define LOCKED (1 << PG_locked)
>
>  #ifdef CONFIG_SLUB_DEBUG
>  #define SLABDEBUG (1 << PG_error)
> @@ -108,36 +109,6 @@
>  #define SLABDEBUG 0
>  #endif
>
> -static inline int SlabFrozen(struct page *page)
> -{
> - return page->flags & FROZEN;
> -}
> -
> -static inline void SetSlabFrozen(struct page *page)
> -{
> - page->flags |= FROZEN;
> -}
> -
> -static inline void ClearSlabFrozen(struct page *page)
> -{
> - page->flags &= ~FROZEN;
> -}
> -
> -static inline int SlabDebug(struct page *page)
> -{
> - return page->flags & SLABDEBUG;
> -}
> -
> -static inline void SetSlabDebug(struct page *page)
> -{
> - page->flags |= SLABDEBUG;
> -}
> -
> -static inline void ClearSlabDebug(struct page *page)
> -{
> - page->flags &= ~SLABDEBUG;
> -}
> -
>  /*
>   * Issues still to be resolved:
>   *
> @@ -818,11 +789,12 @@ static void trace(struct kmem_cache *s,
>  /*
>   * Tracking of fully allocated slabs for debugging purposes.
>   */
> -static void add_full(struct kmem_cache *s, struct page *page)
> +static void add_full(struct kmem_cache *s, struct page *page,
> + unsigned long state)
>  {
>   struct kmem_cache_node *n = get_node(s, page_to_nid(page));
>
> - if (!SlabDebug(page) || !(s->flags & SLAB_STORE_USER))
> + if (!(state & SLABDEBUG) || !(s->flags & SLAB_STORE_USER))
>   return;
>   spin_lock(>list_lock);
>   list_add(>lru, >full);
> @@ -894,7 +866,7 @@ bad:
>  }
>
>  static noinline int free_debug_processing(struct kmem_cache *s,
> - struct page *page, void *object, void *addr)
> + struct page *page, void *object, void *addr, unsigned long state)
>  {
>   if (!check_slab(s, page))
>   goto fail;
> @@ -930,7 +902,7 @@ static noinline int free_debug_processin
>   }
>
>   /* Special debug activities for freeing objects */
> - if (!SlabFrozen(page) && page->freelist == page->end)
> + if (!(state & FROZEN) && page->freelist == page->end)
>   remove_full(s, page);
>   if (s->flags & SLAB_STORE_USER)
>   set_track(s, object, TRACK_FREE, addr);
> @@ -1047,7 +1019,8 @@ static inline int slab_pad_check(struct
>   { return 1; }
>  static inline int check_object(struct kmem_cache *s, struct page *page,
>   void *object, int active) { return 1; }
> -static inline void add_full(struct kmem_cache *s, struct page *page) {}
> +static inline void add_full(struct kmem_cache *s, struct page *page,
> + unsigned long state) {}
>  static inline unsigned long kmem_cache_flags(unsigned long objsize,
>   unsigned long flags, const char *name,
>   void (*ctor)(struct kmem_cache *, void *))
> @@ -1105,6 +1078,7 @@ static noinline struct page *new_slab(st
>   void *start;
>   void *last;
>   void *p;
> + unsigned long state;
>
>   BUG_ON(flags & GFP_SLAB_BUG_MASK);
>
> @@ -1117,11 +1091,12 @@ static noinline struct page *new_slab(st
>   if (n)
>   atomic_long_inc(>nr_slabs);
>   page->slab = s;
> - page->flags |= 1 << PG_slab;
> + state = 1 << PG_slab;
>   if (s->flags & (SLAB_DEBUG_FREE | SLAB_RED_ZONE | SLAB_POISON |
>   SLAB_STORE_USER | SLAB_TRACE))
> - SetSlabDebug(page);
> + state |= SLABDEBUG;
>
> 

Re: [stable] 2.6.23 regression: top displaying 9999% CPU usage

[Christian Borntraeger]

Am Montag, 29. Oktober 2007 schrieb Balbir Singh:
> We'll also need this additional patch (untested), but in the long run
> I think the approach needs to be
> 
> 1. Update stime and utime at the time of context switching -- keep it
>in sync with p->sum_exec_runtime
> 2. Keep track of system/user context at system call entry points

This is similar to what s390 and ppc64 do when CONFIG_VIRT_CPU_ACCOUNTING is 
set. Whenever you do a patch, please make sure to not break the already 
precise values for utime and stime on s390 and ppc. Feel free to CC me 
whenever you have a patch for this.

Christian
-
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 4/4 -v5] x86_64 EFI runtime service support: remove duplicated code from efi_32.c

[Huang, Ying]

This patch removes the duplicated code between efi_32.c and efi.c.

---

 arch/x86/kernel/Makefile_32 |2 
 arch/x86/kernel/e820_32.c   |5 
 arch/x86/kernel/efi_32.c|  430 
 arch/x86/kernel/setup_32.c  |   11 -
 include/asm-x86/efi.h   |   37 +++
 5 files changed, 42 insertions(+), 443 deletions(-)

Signed-off-by: Huang Ying <[EMAIL PROTECTED]>

Index: linux-2.6.24-rc1/arch/x86/kernel/Makefile_32
===
--- linux-2.6.24-rc1.orig/arch/x86/kernel/Makefile_32   2007-10-30 
11:05:57.0 +0800
+++ linux-2.6.24-rc1/arch/x86/kernel/Makefile_322007-10-30 
11:10:33.0 +0800
@@ -34,7 +34,7 @@
 obj-$(CONFIG_MODULES)  += module_32.o
 obj-y  += sysenter_32.o vsyscall_32.o
 obj-$(CONFIG_ACPI_SRAT)+= srat_32.o
-obj-$(CONFIG_EFI)  += efi_32.o efi_stub_32.o
+obj-$(CONFIG_EFI)  += efi.o efi_32.o efi_stub_32.o
 obj-$(CONFIG_DOUBLEFAULT)  += doublefault_32.o
 obj-$(CONFIG_VM86) += vm86_32.o
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
Index: linux-2.6.24-rc1/arch/x86/kernel/efi_32.c
===
--- linux-2.6.24-rc1.orig/arch/x86/kernel/efi_32.c  2007-10-30 
11:05:57.0 +0800
+++ linux-2.6.24-rc1/arch/x86/kernel/efi_32.c   2007-10-30 11:10:33.0 
+0800
@@ -39,21 +39,8 @@
 #include 
 #include 
 
-#define EFI_DEBUG  0
 #define PFX"EFI: "
 
-extern efi_status_t asmlinkage efi_call_phys(void *, ...);
-
-struct efi efi;
-EXPORT_SYMBOL(efi);
-static struct efi efi_phys;
-struct efi_memory_map memmap;
-
-/*
- * We require an early boot_ioremap mapping mechanism initially
- */
-extern void * boot_ioremap(unsigned long, unsigned long);
-
 /*
  * To make EFI call EFI runtime service in physical addressing mode we need
  * prelog/epilog before/after the invocation to disable interrupt, to
@@ -65,7 +52,7 @@
 static DEFINE_SPINLOCK(efi_rt_lock);
 static pgd_t efi_bak_pg_dir_pointer[2];
 
-static void efi_call_phys_prelog(void) __acquires(efi_rt_lock)
+void efi_call_phys_prelog(void) __acquires(efi_rt_lock)
 {
unsigned long cr4;
unsigned long temp;
@@ -108,7 +95,7 @@
load_gdt(_descr);
 }
 
-static void efi_call_phys_epilog(void) __releases(efi_rt_lock)
+void efi_call_phys_epilog(void) __releases(efi_rt_lock)
 {
unsigned long cr4;
struct Xgt_desc_struct gdt_descr;
@@ -138,87 +125,6 @@
spin_unlock(_rt_lock);
 }
 
-static efi_status_t
-phys_efi_set_virtual_address_map(unsigned long memory_map_size,
-unsigned long descriptor_size,
-u32 descriptor_version,
-efi_memory_desc_t *virtual_map)
-{
-   efi_status_t status;
-
-   efi_call_phys_prelog();
-   status = efi_call_phys(efi_phys.set_virtual_address_map,
-memory_map_size, descriptor_size,
-descriptor_version, virtual_map);
-   efi_call_phys_epilog();
-   return status;
-}
-
-static efi_status_t
-phys_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
-{
-   efi_status_t status;
-
-   efi_call_phys_prelog();
-   status = efi_call_phys(efi_phys.get_time, tm, tc);
-   efi_call_phys_epilog();
-   return status;
-}
-
-inline int efi_set_rtc_mmss(unsigned long nowtime)
-{
-   int real_seconds, real_minutes;
-   efi_status_tstatus;
-   efi_time_t  eft;
-   efi_time_cap_t  cap;
-
-   spin_lock(_rt_lock);
-   status = efi.get_time(, );
-   spin_unlock(_rt_lock);
-   if (status != EFI_SUCCESS)
-   panic("Ooops, efitime: can't read time!\n");
-   real_seconds = nowtime % 60;
-   real_minutes = nowtime / 60;
-
-   if (((abs(real_minutes - eft.minute) + 15)/30) & 1)
-   real_minutes += 30;
-   real_minutes %= 60;
-
-   eft.minute = real_minutes;
-   eft.second = real_seconds;
-
-   if (status != EFI_SUCCESS) {
-   printk("Ooops: efitime: can't read time!\n");
-   return -1;
-   }
-   return 0;
-}
-/*
- * This is used during kernel init before runtime
- * services have been remapped and also during suspend, therefore,
- * we'll need to call both in physical and virtual modes.
- */
-inline unsigned long efi_get_time(void)
-{
-   efi_status_t status;
-   efi_time_t eft;
-   efi_time_cap_t cap;
-
-   if (efi.get_time) {
-   /* if we are in virtual mode use remapped function */
-   status = efi.get_time(, );
-   } else {
-   /* we are in physical mode */
-   status = phys_efi_get_time(, );
-   }
-
-   if (status != EFI_SUCCESS)
-   printk("Oops: efitime: can't read time status: 0x%lx\n",status);
-
-   return mktime(eft.year, eft.month, 

[PATCH] serial: fix compiling warning about putc

[Yinghai Lu]

[PATCH] serial: fix compiling warning about putc

CC  drivers/serial/8250_early.o
drivers/serial/8250_early.c:80: warning: conflicting types for built-in 
function ‘putc’

Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>

diff --git a/drivers/serial/8250_early.c b/drivers/serial/8250_early.c
index 4d4c9f0..1f16de7 100644
--- a/drivers/serial/8250_early.c
+++ b/drivers/serial/8250_early.c
@@ -76,7 +76,7 @@ static void __init wait_for_xmitr(struct uart_port *port)
}
 }
 
-static void __init putc(struct uart_port *port, int c)
+static void __init serial_putc(struct uart_port *port, int c)
 {
wait_for_xmitr(port);
serial_out(port, UART_TX, c);
@@ -91,7 +91,7 @@ static void __init early_serial8250_write(struct console 
*console, const char *s
ier = serial_in(port, UART_IER);
serial_out(port, UART_IER, 0);
 
-   uart_console_write(port, s, count, putc);
+   uart_console_write(port, s, count, serial_putc);
 
/* Wait for transmitter to become empty and restore the IER */
wait_for_xmitr(port);
-
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 3/4 -v5] x86_64 EFI runtime service support: document for EFI runtime services

[Huang, Ying]

This patch adds document for EFI x86_64 runtime services support.

---

 boot-options.txt |   11 ++-
 uefi.txt |9 +
 2 files changed, 19 insertions(+), 1 deletion(-)

Signed-off-by: Chandramouli Narayanan <[EMAIL PROTECTED]>
Signed-off-by: Huang Ying <[EMAIL PROTECTED]>

Index: linux-2.6.24-rc1/Documentation/x86_64/boot-options.txt
===
--- linux-2.6.24-rc1.orig/Documentation/x86_64/boot-options.txt 2007-10-30 
10:15:00.0 +0800
+++ linux-2.6.24-rc1/Documentation/x86_64/boot-options.txt  2007-10-30 
10:23:52.0 +0800
@@ -110,12 +110,15 @@
 
 Rebooting
 
-   reboot=b[ios] | t[riple] | k[bd] [, [w]arm | [c]old]
+   reboot=b[ios] | t[riple] | k[bd] | e[fi] [, [w]arm | [c]old]
bios  Use the CPU reboot vector for warm reset
warm   Don't set the cold reboot flag
cold   Set the cold reboot flag
triple Force a triple fault (init)
kbdUse the keyboard controller. cold reset (default)
+   efiUse efi reset_system runtime service. If EFI is not configured or the
+  EFI reset does not work, the reboot path attempts the reset using
+  the keyboard controller.
 
Using warm reset will be much faster especially on big memory
systems because the BIOS will not go through the memory check.
@@ -300,4 +303,10 @@
newfallback: use new unwinder but fall back to old if it gets
stuck (default)
 
+EFI
+
+  noefiDisable EFI support
+
+  efi_time=on  Enable EFI time runtime service
+
 Miscellaneous
Index: linux-2.6.24-rc1/Documentation/x86_64/uefi.txt
===
--- linux-2.6.24-rc1.orig/Documentation/x86_64/uefi.txt 2007-10-30 
10:15:00.0 +0800
+++ linux-2.6.24-rc1/Documentation/x86_64/uefi.txt  2007-10-30 
10:25:39.0 +0800
@@ -19,6 +19,10 @@
 - Build the kernel with the following configuration.
CONFIG_FB_EFI=y
CONFIG_FRAMEBUFFER_CONSOLE=y
+  If EFI runtime services are expected, the following configuration should
+  be selected.
+   CONFIG_EFI=y
+   CONFIG_EFI_VARS=y or m  # optional
 - Create a VFAT partition on the disk
 - Copy the following to the VFAT partition:
elilo bootloader with x86_64 support, elilo configuration file,
@@ -27,3 +31,8 @@
can be found in the elilo sourceforge project.
 - Boot to EFI shell and invoke elilo choosing the kernel image built
   in first step.
+- If some or all EFI runtime services don't work, you can try following
+  kernel command line parameters to turn off some or all EFI runtime
+  services.
+   noefi   turn off all EFI runtime services
+   reboot_type=k   turn off EFI reboot runtime service
-
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 2/4 -v5] x86_64 EFI runtime service support: EFI runtime services

[Huang, Ying]

This patch adds support for several EFI runtime services for EFI
x86_64 system.

The EFI support for emergency_restart and RTC clock is added. The EFI
based implementation and legacy BIOS or CMOS based implementation are
put in separate functions and can be chosen with kernel boot options.

Signed-off-by: Chandramouli Narayanan <[EMAIL PROTECTED]>
Signed-off-by: Huang Ying <[EMAIL PROTECTED]>

---

 arch/x86/kernel/reboot_64.c |   19 +-
 arch/x86/kernel/time_64.c   |   47 +++-
 include/asm-x86/emergency-restart.h |8 ++
 include/asm-x86/time.h  |   47 +++-
 include/asm-x86/time_32.h   |   44 +
 include/asm-x86/time_64.h   |7 +
 6 files changed, 107 insertions(+), 65 deletions(-)

Index: linux-2.6.24-rc1/arch/x86/kernel/reboot_64.c
===
--- linux-2.6.24-rc1.orig/arch/x86/kernel/reboot_64.c   2007-10-30 
10:15:03.0 +0800
+++ linux-2.6.24-rc1/arch/x86/kernel/reboot_64.c2007-10-30 
10:22:00.0 +0800
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -26,18 +27,16 @@
 EXPORT_SYMBOL(pm_power_off);
 
 static long no_idt[3];
-static enum { 
-   BOOT_TRIPLE = 't',
-   BOOT_KBD = 'k'
-} reboot_type = BOOT_KBD;
+enum reboot_type reboot_type = BOOT_KBD;
 static int reboot_mode = 0;
 int reboot_force;
 
-/* reboot=t[riple] | k[bd] [, [w]arm | [c]old]
+/* reboot=t[riple] | k[bd] | e[fi] [, [w]arm | [c]old]
warm   Don't set the cold reboot flag
cold   Set the cold reboot flag
triple Force a triple fault (init)
kbdUse the keyboard controller. cold reset (default)
+   efiUse efi reset_system runtime service
force  Avoid anything that could hang.
  */ 
 static int __init reboot_setup(char *str)
@@ -55,6 +54,7 @@
case 't':
case 'b':
case 'k':
+   case 'e':
reboot_type = *str;
break;
case 'f':
@@ -142,7 +142,14 @@
 
reboot_type = BOOT_KBD;
break;
-   }  
+
+   case BOOT_EFI:
+   if (efi_enabled)
+   efi.reset_system(reboot_mode ? EFI_RESET_WARM : 
EFI_RESET_COLD,
+EFI_SUCCESS, 0, NULL);
+   reboot_type = BOOT_KBD;
+   break;
+   }
}  
 }
 
Index: linux-2.6.24-rc1/arch/x86/kernel/time_64.c
===
--- linux-2.6.24-rc1.orig/arch/x86/kernel/time_64.c 2007-10-30 
10:15:03.0 +0800
+++ linux-2.6.24-rc1/arch/x86/kernel/time_64.c  2007-10-30 10:22:04.0 
+0800
@@ -45,12 +45,19 @@
 #include 
 #include 
 #include 
+#include 
 
 DEFINE_SPINLOCK(rtc_lock);
 EXPORT_SYMBOL(rtc_lock);
 
 volatile unsigned long __jiffies __section_jiffies = INITIAL_JIFFIES;
 
+static int set_rtc_mmss(unsigned long nowtime);
+static unsigned long read_cmos_clock(void);
+
+unsigned long (*get_wallclock)(void) = read_cmos_clock;
+int (*set_wallclock)(unsigned long nowtime) = set_rtc_mmss;
+
 unsigned long profile_pc(struct pt_regs *regs)
 {
unsigned long pc = instruction_pointer(regs);
@@ -84,13 +91,6 @@
unsigned char control, freq_select;
 
 /*
- * IRQs are disabled when we're called from the timer interrupt,
- * no need for spin_lock_irqsave()
- */
-
-   spin_lock(_lock);
-
-/*
  * Tell the clock it's being set and stop it.
  */
 
@@ -138,14 +138,23 @@
CMOS_WRITE(control, RTC_CONTROL);
CMOS_WRITE(freq_select, RTC_FREQ_SELECT);
 
-   spin_unlock(_lock);
-
return retval;
 }
 
 int update_persistent_clock(struct timespec now)
 {
-   return set_rtc_mmss(now.tv_sec);
+   int retval;
+
+/*
+ * IRQs are disabled when we're called from the timer interrupt,
+ * no need for spin_lock_irqsave()
+ */
+
+   spin_lock(_lock);
+   retval = set_wallclock(now.tv_sec);
+   spin_unlock(_lock);
+
+   return retval;
 }
 
 static irqreturn_t timer_event_interrupt(int irq, void *dev_id)
@@ -157,14 +166,11 @@
return IRQ_HANDLED;
 }
 
-unsigned long read_persistent_clock(void)
+static unsigned long read_cmos_clock(void)
 {
unsigned int year, mon, day, hour, min, sec;
-   unsigned long flags;
unsigned century = 0;
 
-   spin_lock_irqsave(_lock, flags);
-
do {
sec = CMOS_READ(RTC_SECONDS);
min = CMOS_READ(RTC_MINUTES);
@@ -179,8 +185,6 @@
 #endif
} while (sec != CMOS_READ(RTC_SECONDS));
 
-   spin_unlock_irqrestore(_lock, flags);
-
/*
 * We know that x86-64 always uses BCD format, no need to check the
 * config register.
@@ -208,6 +212,17 @@

[PATCH 0/4 -v5] x86_64 EFI runtime service support

[Huang, Ying]

Following patchset adds EFI/UEFI (Unified Extensible Firmware
Interface) runtime services support to x86_64 architecture.

The patchset have been tested against 2.6.24-rc1 kernel on Intel
platforms with 64-bit EFI1.10 and UEFI2.0 firmware. Because the
duplicated code between efi_32.c and efi_64.c is removed, the patchset
is also tested on Intel platform with 32-bit EFI firmware.


v5:

- Remove the duplicated code between efi_32.c and efi_64.c.

- Rename lin2win to efi_call.

- Make EFI time runtime service default to off.

- Use different bootloader signature for EFI32 and EFI64, so that
  kernel can know whether underlaying EFI firmware is 64-bit or
  32-bit.

v4:

- EFI boot parameters are extended for 64-bit EFI in a 32-bit EFI
  compatible way.

- Add EFI runtime services document.

v3:

- Remove E820_RUNTIME_CODE, the EFI memory map is used to deal with
  EFI runtime code area.

- The method used to make EFI runtime code area executable is change:

  a. Before page allocation is usable, the PMD of direct mapping is
 changed temporarily before and after each EFI call.

  b. After page allocation is usable, change_page_attr_addr is used to
 change corresponding page attribute.

- Use fixmap to map EFI memory mapped IO memory area to make kexec
  workable.

- Add a kernel command line option "noefi" to make it possible to turn
  off EFI runtime services support.

- Function pointers are used for EFI time runtime service.

- EFI reboot runtime service is embedded into the framework of
  reboot_type.

- A kernel command line option "noefi_time" is added to make it
  possible to fall back to CMOS based implementation.

v2:

- The EFI callwrapper is re-implemented in assembler.


Best Regards,
Huang Ying
-
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 1/4 -v5] x86_64 EFI runtime service support: EFI basic runtime service support

[Huang, Ying]

This patch adds basic runtime services support for EFI x86_64
system. The main file of the patch is the addition of efi_64.c for
x86_64. This file is modeled after the EFI IA32 avatar. EFI runtime
services initialization are implemented in efi_64.c. Some x86_64
specifics are worth noting here. On x86_64, parameters passed to EFI
firmware services need to follow the EFI calling convention. For this
purpose, a set of functions named efi_call ( is the number of
parameters) are implemented. EFI function calls are wrapped before
calling the firmware service. The duplicated code between efi_32.c and
efi_64.c is placed in efi.c to remove them from efi_32.c.

Signed-off-by: Chandramouli Narayanan <[EMAIL PROTECTED]>
Signed-off-by: Huang Ying <[EMAIL PROTECTED]>

---

 arch/x86/kernel/Makefile_64   |1 
 arch/x86/kernel/efi.c |  483 ++
 arch/x86/kernel/efi_64.c  |  181 +++
 arch/x86/kernel/efi_stub_64.S |   68 +
 arch/x86/kernel/setup_64.c|   17 +
 arch/x86_64/Kconfig   |   11 
 include/asm-x86/bootparam.h   |5 
 include/asm-x86/efi.h |   70 ++
 include/asm-x86/fixmap_64.h   |3 
 9 files changed, 836 insertions(+), 3 deletions(-)

Index: linux-2.6.24-rc1/arch/x86/kernel/efi_64.c
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ linux-2.6.24-rc1/arch/x86/kernel/efi_64.c   2007-10-30 10:07:57.0 
+0800
@@ -0,0 +1,181 @@
+/*
+ * x86_64 specific EFI support functions
+ * Based on Extensible Firmware Interface Specification version 1.0
+ *
+ * Copyright (C) 2005-2008 Intel Co.
+ * Fenghua Yu <[EMAIL PROTECTED]>
+ * Bibo Mao <[EMAIL PROTECTED]>
+ * Chandramouli Narayanan <[EMAIL PROTECTED]>
+ * Huang Ying <[EMAIL PROTECTED]>
+ *
+ * Code to convert EFI to E820 map has been implemented in elilo bootloader
+ * based on a EFI patch by Edgar Hucek. Based on the E820 map, the page table
+ * is setup appropriately for EFI runtime code.
+ * - mouli 06/14/2007.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int efi_time __initdata;
+
+static pgd_t save_pgd __initdata;
+static unsigned long efi_flags __initdata;
+/* efi_lock protects efi physical mode call */
+static __initdata DEFINE_SPINLOCK(efi_lock);
+
+static int __init setup_noefi(char *arg)
+{
+   efi_enabled = 0;
+   return 0;
+}
+early_param("noefi", setup_noefi);
+
+static int __init setup_efi_time(char *arg)
+{
+   if (arg && !strcmp("on", arg))
+   efi_time = 1;
+   return 0;
+}
+early_param("efi_time", setup_efi_time);
+
+static void __init early_mapping_set_exec(unsigned long start,
+ unsigned long end,
+ int executable)
+{
+   pte_t *kpte;
+
+   while (start < end) {
+   kpte = lookup_address((unsigned long)__va(start));
+   BUG_ON(!kpte);
+   if (executable)
+   set_pte(kpte, pte_mkexec(*kpte));
+   else
+   set_pte(kpte, __pte((pte_val(*kpte) | _PAGE_NX) & \
+   __supported_pte_mask));
+   if (pte_huge(*kpte))
+   start = (start + PMD_SIZE) & PMD_MASK;
+   else
+   start = (start + PAGE_SIZE) & PAGE_MASK;
+   }
+}
+
+static void __init early_runtime_code_mapping_set_exec(int executable)
+{
+   efi_memory_desc_t *md;
+   void *p;
+
+   /* Make EFI runtime service code area executable */
+   for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
+   md = p;
+   if (md->type == EFI_RUNTIME_SERVICES_CODE) {
+   unsigned long end;
+   end = md->phys_addr + (md->num_pages << PAGE_SHIFT);
+   early_mapping_set_exec(md->phys_addr, end, executable);
+   }
+   }
+}
+
+void __init efi_call_phys_prelog(void) __acquires(efi_lock)
+{
+   unsigned long vaddress;
+
+   /*
+* Lock sequence is different from normal case because
+* efi_flags is global
+*/
+   spin_lock(_lock);
+   local_irq_save(efi_flags);
+   early_runtime_code_mapping_set_exec(1);
+   vaddress = (unsigned long)__va(0x0UL);
+   pgd_val(save_pgd) = pgd_val(*pgd_offset_k(0x0UL));
+   set_pgd(pgd_offset_k(0x0UL), *pgd_offset_k(vaddress));
+   global_flush_tlb();
+}
+
+void __init efi_call_phys_epilog(void) __releases(efi_lock)
+{
+   /*
+* After the lock is released, the original page table is restored.
+*/
+   set_pgd(pgd_offset_k(0x0UL), save_pgd);
+   early_runtime_code_mapping_set_exec(0);
+   

Re: [PATCH 1/2] [CRYPTO] tcrypt: Move sg_init_table out of timing loops

[Jens Axboe]

On Tue, Oct 30 2007, Herbert Xu wrote:
> On Mon, Oct 29, 2007 at 09:16:27PM +0100, Jens Axboe wrote:
> > On Fri, Oct 26 2007, Herbert Xu wrote:
> > > [CRYPTO] tcrypt: Move sg_init_table out of timing loops
> > > 
> > > This patch moves the sg_init_table out of the timing loops for hash
> > > algorithms so that it doesn't impact on the speed test results.
> > 
> > Wouldn't it be better to just make sg_init_one() call sg_init_table?
> 
> This looks fine to me although I think it's orthogonal to the
> patch you were quoting :)

How so? The reason you changed it to sg_init_table() + sg_set_buf() is
exactly because sg_init_one() didn't properly init the entry (as they
name promised).

-- 
Jens Axboe

-
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: XFS Fails Quality Assurance Tests on ARM

[Eric Sandeen]

Andi Kleen wrote:
> David Miller <[EMAIL PROTECTED]> writes:
> 
>> From: Byron Bradley <[EMAIL PROTECTED]>
>> Date: Fri, 31 Aug 2007 03:12:46 + (UTC)
>>
>>> Anybody got any ideas of how we fix this?
>> I don't know how much testing XFS gets on ARM, but one thing that some
>> ARM chips have is D-cache aliasing problems and one thing XFS uses a
>> lot is virtual remapping of various data structures via vmap().
>>
>> This might be what is causing the problems.

Sorry, I lost the original to reply to, but stumbled on this thread
looking for something else.  :)

Anyway, from the assertion:

Assertion failed: (char *)sfep - (char *)sfp == dp->i_d.di_size, file:
fs/xfs/xfs_dir2_sf.c, line: 647 kernel BUG at fs/xfs/support/debug.c:82!

this is almost certainly a result of xfs_dir2_sf_off_t,
xfs_dir2_sf_hdr_t, and/or xfs_dir2_sf_entry_t or others not being
"properly" aligned on arm.

There was a patch floating around to "fix" it but it's not on-disk
compatible w/ x86 & friends, it just makes things consistent for arm.  I
think packing some of these structures would take care of it, but this
problem could use some attention & testing I think, it's been floating
around a long time.

-Eric
-
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: CONFIG_IDEDMA_AUTO & 2.4.32 & hdparm -d1

[Willy Tarreau]

On Mon, Oct 29, 2007 at 05:45:52PM -0400, Lennart Sorensen wrote:
> On Mon, Oct 29, 2007 at 09:52:35PM +0100, Wijnand Rietman wrote:
> > Thanks Lens for the suggestion!
> > 
> > Unfortunately this option doesn't work either. When I pass the "nodma"
> > paramater to the kernel, it boots with DMA disabled (like it should),
> > but doesn't allow DMA to be enabled anymore with hdparm.
> 
> Hmm, I was pretty sure I had the ability to turn it on after the fact
> before.  Perhaps I was wrong.  That would be silly.  There has to be
> some option to do what you want.

I too had to completely disable the config option with some CF which
caused long timeouts at boot time. I don't remember having been able
to re-enable anything afterwards (including other hard disks).

Willy

-
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: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Peter Dolding]

On 10/30/07, Crispin Cowan <[EMAIL PROTECTED]> wrote:
> Ah! So the proposal really is to have an LSM maintainer for each
> "family" of models, acting as a resource and arbiter for modules in a class.

I see it a little bit different one LSM maintainer for the lot of
modules who kicks the ass's of thoses who are not prepaid to share.
>
> I like that idea, and have no objection to it. However, it does have
> resource problems, in that the pool of LSM maintainers is not that
> large. There is also the likely objection that this degree of scale is
> not needed until at least there are multiple families of models in the
> upstream kernel, and possibly until there are multiple instances of a
> single family in the upstream kernel.
>
> It also begs the question of what constitutes a family.
>
> * AppArmor, SELinux, and TOMOYO are all ambient capability systems
>   o AppArmor and TOMOYO are pathname based
>   o SELinux is label based

Here as always all three should see where they can share code and get
the best performance this might mean AppArmor and Tomoyo use Selinux
labels because it causes less overhead.  Or Selinux provides a
optional path based using the other engine.  Both are providing the
same feature in different ways.   Question does have to be asked is
there bench testable justification for need two for file systems
filters.

> * SELinux and SMACK are label-based
>   o I don't know if SMACK is an ambient capability system

Both of these are sharing backwards and forwards between each other so
being nice with each other.  LSM overall Maintainer only really need
to at worst way xyz sections are not merged/shared and to document why
with benchmarks if they are not going to be.  Ie tested reason.

> * Rob Meijer implicitly advocated for an object capability LSM
>   o would it be pathname or label based? You could do either or
> both ...
Both is a valid answer.   Sections done path based should be shared
with other path based and labal based shared with other label based.

> * The LSPP work from RH, Tresys, and TCS is MLS based
>   o this is a subset of both label-based and ambient capability
> based
Ok section by section where would it be best for that code base to share with.

> * I have no clue what family to put MultiADM or Dazuko into
MultiADMIN falls under o my god head ache.  This is more a posix
standard feature altered ie 1 root user turned into many.  This really
risks breaking the other models as a LSM.  Its more of a all in or all
out.  Really it needs to be lowered out of LSM into a standard
optional Linux feature so it cannot breach the security of other LSM
modules.  Also LSM modules will need to be made able to tell a
MultiADMIN root users.  This is part of what I was talking about some
parts need to be as lower down module not at full blown LSM level.
This is the rare one where the complete model needs to be moved down.
There are bits in almost all LSM that need to be looked at being made
full time features of linux like quotas and posix file capability's .

Dazuko is the rare user mode controlled interface.  Still same rule
share code where able.  Anti-Virus integration and other protecting
systems are commonly overlooked by LSM's.Same here if this should
be a LSM or a kernel optional feature independent to LSM that a LSM
can block from happening.

> * Getting very formal, I could imagine a Clarke-Wilson module
> * Getting very informal, I could imagine a module that is a
>   collection of cute intrusion prevention hacks, such as the Open
>   wall Linux symlink and hardlink restrictions, and my own RaceGuard
>   work
>   o Oh wait, I published
> 
> RaceGuard. Does that make it formal? :-)
>
You will hate me but I don't call that formal enough.  Its lacks the
critical bit of doc written in terms that any system admin can
understand what they are being given.

Next question should RaceGuard be a LSM at all.  Or should it be a
standard feature what LSM can over rule? 

Lot of things are being pushed as LSM's when they should be pushed as
expanded default features outside LSM.

Peter Dolding
-
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] rpc_rdma: we need to cast u64 to unsigned long long for printing

[Stephen Rothwell]

as some architectures have unsigned long for u64.

net/sunrpc/xprtrdma/rpc_rdma.c: In function 'rpcrdma_create_chunks':
net/sunrpc/xprtrdma/rpc_rdma.c:222: warning: format '%llx' expects type 'long 
long unsigned int', but argument 4 has type 'u64'
net/sunrpc/xprtrdma/rpc_rdma.c:234: warning: format '%llx' expects type 'long 
long unsigned int', but argument 5 has type 'u64'
net/sunrpc/xprtrdma/rpc_rdma.c: In function 'rpcrdma_count_chunks':
net/sunrpc/xprtrdma/rpc_rdma.c:577: warning: format '%llx' expects type 'long 
long unsigned int', but argument 4 has type 'u64

Noticed on PowerPC pseries_defconfig build.

Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
 net/sunrpc/xprtrdma/rpc_rdma.c |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]

diff --git a/net/sunrpc/xprtrdma/rpc_rdma.c b/net/sunrpc/xprtrdma/rpc_rdma.c
index f877b88..9e11ce7 100644
--- a/net/sunrpc/xprtrdma/rpc_rdma.c
+++ b/net/sunrpc/xprtrdma/rpc_rdma.c
@@ -221,8 +221,8 @@ rpcrdma_create_chunks(struct rpc_rqst *rqst, struct xdr_buf 
*target,
seg->mr_base);
dprintk("RPC:   %s: read chunk "
"elem [EMAIL PROTECTED]:0x%x pos %d (%s)\n", 
__func__,
-   seg->mr_len, seg->mr_base, seg->mr_rkey, pos,
-   n < nsegs ? "more" : "last");
+   seg->mr_len, (unsigned long long)seg->mr_base,
+   seg->mr_rkey, pos, n < nsegs ? "more" : "last");
cur_rchunk++;
r_xprt->rx_stats.read_chunk_count++;
} else {/* write/reply */
@@ -234,8 +234,8 @@ rpcrdma_create_chunks(struct rpc_rqst *rqst, struct xdr_buf 
*target,
dprintk("RPC:   %s: %s chunk "
"elem [EMAIL PROTECTED]:0x%x (%s)\n", __func__,
(type == rpcrdma_replych) ? "reply" : "write",
-   seg->mr_len, seg->mr_base, seg->mr_rkey,
-   n < nsegs ? "more" : "last");
+   seg->mr_len, (unsigned long long)seg->mr_base,
+   seg->mr_rkey, n < nsegs ? "more" : "last");
cur_wchunk++;
if (type == rpcrdma_replych)
r_xprt->rx_stats.reply_chunk_count++;
@@ -577,7 +577,7 @@ rpcrdma_count_chunks(struct rpcrdma_rep *rep, int max, int 
wrchunk, __be32 **ipt
dprintk("RPC:   %s: chunk [EMAIL PROTECTED]:0x%x\n",
__func__,
ntohl(seg->rs_length),
-   off,
+   (unsigned long long)off,
ntohl(seg->rs_handle));
}
total_len += ntohl(seg->rs_length);
-- 
1.5.3.4

-
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 patch] ia64/mm/init.c: fix section mismatches

[Simon Horman]

On Mon, Oct 29, 2007 at 01:49:47PM +0100, Adrian Bunk wrote:
> This patch fixes the following section mismatches:
> 
> <--  snip  -->
> 
> ...
> WARNING: vmlinux.o(.text+0x5b5c2): Section mismatch: reference to 
> .init.text:memmap_init_zone (between 'memmap_init' and 'virtual_memmap_init')
> WARNING: vmlinux.o(.text+0x5b842): Section mismatch: reference to 
> .init.text:memmap_init_zone (between 'virtual_memmap_init' and 
> 'ia64_mmu_init')
> ...
> 
> <--  snip  -->
> 
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

That seems correct me and makes the warnings go away in my build.

Acked-by: Simon Horman <[EMAIL PROTECTED]>

> 
> ---
> 
>  arch/ia64/mm/init.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> 45c99ede63b0f76fe3dcc906ae550193a4d41626 
> diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
> index c6c19bf..25aef62 100644
> --- a/arch/ia64/mm/init.c
> +++ b/arch/ia64/mm/init.c
> @@ -472,7 +472,7 @@ struct memmap_init_callback_data {
>   unsigned long zone;
>  };
>  
> -static int
> +static int __meminit
>  virtual_memmap_init (u64 start, u64 end, void *arg)
>  {
>   struct memmap_init_callback_data *args;
> @@ -503,7 +503,7 @@ virtual_memmap_init (u64 start, u64 end, void *arg)
>   return 0;
>  }
>  
> -void
> +void __meminit
>  memmap_init (unsigned long size, int nid, unsigned long zone,
>unsigned long start_pfn)
>  {
> 
> -
> 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: BUG in sys_socketpair

[David Miller]

From: Chuck Ebbert <[EMAIL PROTECTED]>
Date: Thu, 25 Oct 2007 14:44:52 -0400

> On 10/25/2007 10:11 AM, Rich Paul wrote:
> > In 2.6.23, there seems to be a minor bug in sys_socketpair.  When the
> > calls to sock_alloc_fd fail, it aborts the routine, but it returns the
> > variable err, which is not set in this case.
> > 
> > The result is a silent failure if you have too many files open and call
> > socketpair.
> > 
> > Here is a simple UNTESTED patch (not even compiled) which should resolve the
> > issue.
> > 
> > 
> > --- net/socket.c.orig   2007-10-25 10:03:56.0 -0400
> > +++ net/socket.c2007-10-25 10:04:00.0 -0400
> Should be "err = fd1" (spaces), otherwise looks good.
> 
> Original did:
> 
>   err = sock_map_fd(sock1);
>   if (err < 0)
>   goto out_release_both;
>   fd1 = err;

Thanks everyone, I'll commit the following both to 2.6.x GIT
and -stable.

>From 42f3fc7e989554e9952bdf28af137e4e4570f067 Mon Sep 17 00:00:00 2001
From: David S. Miller <[EMAIL PROTECTED]>
Date: Mon, 29 Oct 2007 21:54:02 -0700
Subject: [PATCH] [NET]: Fix error reporting in sys_socketpair().

If either of the two sock_alloc_fd() calls fail, we
forget to update 'err' and thus we'll erroneously
return zero in these cases.

Based upon a report and patch from Rich Paul, and
commentary from Chuck Ebbert.

Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
---
 net/socket.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/net/socket.c b/net/socket.c
index 540013e..5d879fd 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -1250,11 +1250,14 @@ asmlinkage long sys_socketpair(int family, int type, 
int protocol,
goto out_release_both;
 
fd1 = sock_alloc_fd();
-   if (unlikely(fd1 < 0))
+   if (unlikely(fd1 < 0)) {
+   err = fd1;
goto out_release_both;
+   }
 
fd2 = sock_alloc_fd();
if (unlikely(fd2 < 0)) {
+   err = fd2;
put_filp(newfile1);
put_unused_fd(fd1);
goto out_release_both;
-- 
1.5.2.5

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

[M68KNOMMU]: platform setup for 520x ColdFire UARTs

[Greg Ungerer]

Switch to platform style configuration for 520x ColdFire family UARTs.

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---

diff -Naurp linux-2.6.23-rc1/arch/m68knommu/platform/520x/config.c 
linux-2.6.23-rc1.platform/arch/m68knommu/platform/520x/config.c
--- linux-2.6.23-rc1/arch/m68knommu/platform/520x/config.c  2007-10-25 
10:48:36.0 +1000
+++ linux-2.6.23-rc1.platform/arch/m68knommu/platform/520x/config.c 
2007-10-30 14:18:24.0 +1000
@@ -5,7 +5,7 @@
  *
  *  Copyright (C) 2005,  Freescale (www.freescale.com)
  *  Copyright (C) 2005,  Intec Automation ([EMAIL PROTECTED])
- *  Copyright (C) 1999-2003, Greg Ungerer ([EMAIL PROTECTED])
+ *  Copyright (C) 1999-2007, Greg Ungerer ([EMAIL PROTECTED])
  *  Copyright (C) 2001-2003, SnapGear Inc. (www.snapgear.com)
  */
 
@@ -13,9 +13,14 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 
 /***/
 
@@ -31,6 +36,82 @@ void coldfire_reset(void);
 
 /***/
 
+static struct mcf_platform_uart m520x_uart_platform[] = {
+   {
+   .mapbase= MCF_MBAR + MCFUART_BASE1,
+   .irq= MCFINT_VECBASE + MCFINT_UART0,
+   },
+   {
+   .mapbase= MCF_MBAR + MCFUART_BASE2,
+   .irq= MCFINT_VECBASE + MCFINT_UART1,
+   },
+   {
+   .mapbase= MCF_MBAR + MCFUART_BASE3,
+   .irq= MCFINT_VECBASE + MCFINT_UART2,
+   },
+   { },
+};
+
+static struct platform_device m520x_uart = {
+   .name   = "mcfuart",
+   .id = 0,
+   .dev.platform_data  = m520x_uart_platform,
+};
+
+static struct platform_device *m520x_devices[] __initdata = {
+   _uart,
+};
+
+/***/
+
+#defineINTC0   (MCF_MBAR + MCFICM_INTC0)
+
+static void __init m520x_uart_init_line(int line, int irq)
+{
+   u32 imr;
+   u16 par;
+   u8 par2;
+
+   writeb(0x03, INTC0 + MCFINTC_ICR0 + MCFINT_UART0 + line);
+
+   imr = readl(INTC0 + MCFINTC_IMRL);
+   imr &= ~((1 << (irq - MCFINT_VECBASE)) | 1);
+   writel(imr, INTC0 + MCFINTC_IMRL);
+
+   switch (line) {
+   case 0:
+   par = readw(MCF_IPSBAR + MCF_GPIO_PAR_UART);
+   par |= MCF_GPIO_PAR_UART_PAR_UTXD0 |
+  MCF_GPIO_PAR_UART_PAR_URXD0;
+   writew(par, MCF_IPSBAR + MCF_GPIO_PAR_UART);
+   break;
+   case 1:
+   par = readw(MCF_IPSBAR + MCF_GPIO_PAR_UART);
+   par |= MCF_GPIO_PAR_UART_PAR_UTXD1 |
+  MCF_GPIO_PAR_UART_PAR_URXD1;
+   writew(par, MCF_IPSBAR + MCF_GPIO_PAR_UART);
+   break;
+   case 2:
+   par2 = readb(MCF_IPSBAR + MCF_GPIO_PAR_FECI2C);
+   par2 &= ~0x0F;
+   par2 |= MCF_GPIO_PAR_FECI2C_PAR_SCL_UTXD2 |
+   MCF_GPIO_PAR_FECI2C_PAR_SDA_URXD2;
+   writeb(par2, MCF_IPSBAR + MCF_GPIO_PAR_FECI2C);
+   break;
+   }
+}
+
+static void __init m520x_uarts_init(void)
+{
+   const int nrlines = ARRAY_SIZE(m520x_uart_platform);
+   int line;
+
+   for (line = 0; (line < nrlines); line++)
+   m520x_uart_init_line(line, m520x_uart_platform[line].irq);
+}
+
+/***/
+
 /*
  *  Program the vector to be an auto-vectored.
  */
@@ -42,9 +123,20 @@ void mcf_autovector(unsigned int vec)
 
 /***/
 
-void config_BSP(char *commandp, int size)
+void __init config_BSP(char *commandp, int size)
 {
mach_reset = coldfire_reset;
+   m520x_uarts_init();
 }
 
 /***/
+
+static int __init init_BSP(void)
+{
+   platform_add_devices(m520x_devices, ARRAY_SIZE(m520x_devices));
+   return 0;
+}
+
+arch_initcall(init_BSP);
+
+/***/
-
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/

[M68KNOMMU]: platform setup for 5272 ColdFire UARTs

[Greg Ungerer]

Switch to platform style configuration for 5272 ColdFire UARTs.

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---

diff -Naurp linux-2.6.23-rc1/arch/m68knommu/platform/5272/config.c 
linux-2.6.23-rc1.platform/arch/m68knommu/platform/5272/config.c
--- linux-2.6.23-rc1/arch/m68knommu/platform/5272/config.c  2007-10-25 
10:48:36.0 +1000
+++ linux-2.6.23-rc1.platform/arch/m68knommu/platform/5272/config.c 
2007-10-30 14:18:24.0 +1000
@@ -13,11 +13,12 @@
 #include 
 #include 
 #include 
-#include 
 #include 
+#include 
+#include 
 #include 
 #include 
-#include 
+#include 
 
 /***/
 
@@ -48,6 +49,60 @@ unsigned int dma_device_address[MAX_M68K
 
 /***/
 
+static struct mcf_platform_uart m5272_uart_platform[] = {
+   {
+   .mapbase= MCF_MBAR + MCFUART_BASE1,
+   .irq= 73,
+   },
+   {
+   .mapbase= MCF_MBAR + MCFUART_BASE2,
+   .irq= 74,
+   },
+   { },
+};
+
+static struct platform_device m5272_uart = {
+   .name   = "mcfuart",
+   .id = 0,
+   .dev.platform_data  = m5272_uart_platform,
+};
+
+static struct platform_device *m5272_devices[] __initdata = {
+   _uart,
+};
+
+/***/
+
+static void __init m5272_uart_init_line(int line, int irq)
+{
+   u32 v;
+
+   if ((line >= 0) && (line < 2)) {
+   v = (line) ? 0x0e00 : 0xe000;
+   writel(v, MCF_MBAR + MCFSIM_ICR2);
+
+   /* Enable the output lines for the serial ports */
+   v = readl(MCF_MBAR + MCFSIM_PBCNT);
+   v = (v & ~0x00ff) | 0x0055;
+   writel(v, MCF_MBAR + MCFSIM_PBCNT);
+
+   v = readl(MCF_MBAR + MCFSIM_PDCNT);
+   v = (v & ~0x03fc) | 0x02a8;
+   writel(v, MCF_MBAR + MCFSIM_PDCNT);
+   }
+}
+
+static void __init m5272_uarts_init(void)
+{
+   const int nrlines = ARRAY_SIZE(m5272_uart_platform);
+   int line;
+
+   for (line = 0; (line < nrlines); line++)
+   m5272_uart_init_line(line, m5272_uart_platform[line].irq);
+}
+
+/***/
+
 void mcf_disableall(void)
 {
volatile unsigned long  *icrp;
@@ -93,7 +148,7 @@ int mcf_timerirqpending(int timer)
 
 /***/
 
-void config_BSP(char *commandp, int size)
+void __init config_BSP(char *commandp, int size)
 {
 #if defined (CONFIG_MOD5272)
volatile unsigned char  *pivrp;
@@ -109,10 +164,6 @@ void config_BSP(char *commandp, int size
/* Copy command line from FLASH to local buffer... */
memcpy(commandp, (char *) 0xf0004000, size);
commandp[size-1] = 0;
-#elif defined(CONFIG_MTD_KeyTechnology)
-   /* Copy command line from FLASH to local buffer... */
-   memcpy(commandp, (char *) 0xffe06000, size);
-   commandp[size-1] = 0;
 #elif defined(CONFIG_CANCam)
/* Copy command line from FLASH to local buffer... */
memcpy(commandp, (char *) 0xf001, size);
@@ -125,3 +176,14 @@ void config_BSP(char *commandp, int size
 }
 
 /***/
+
+static int __init init_BSP(void)
+{
+   m5272_uarts_init();
+   platform_add_devices(m5272_devices, ARRAY_SIZE(m5272_devices));
+   return 0;
+}
+
+arch_initcall(init_BSP);
+
+/***/
-
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/

[M68KNOMMU]: platform setup for 5206e ColdFire UARTs

[Greg Ungerer]

Switch to platform style configuration for 5206e ColdFire UARTs.

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---

diff -Naurp linux-2.6.23-rc1/arch/m68knommu/platform/5206e/config.c 
linux-2.6.23-rc1.platform/arch/m68knommu/platform/5206e/config.c
--- linux-2.6.23-rc1/arch/m68knommu/platform/5206e/config.c 2007-10-25 
10:48:36.0 +1000
+++ linux-2.6.23-rc1.platform/arch/m68knommu/platform/5206e/config.c
2007-10-30 14:18:24.0 +1000
@@ -10,9 +10,11 @@
 
 #include 
 #include 
+#include 
 #include 
-#include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -35,6 +37,54 @@ unsigned int dma_device_address[MAX_M68K
 
 /***/
 
+static struct mcf_platform_uart m5206_uart_platform[] = {
+   {
+   .mapbase= MCF_MBAR + MCFUART_BASE1,
+   .irq= 73,
+   },
+   {
+   .mapbase= MCF_MBAR + MCFUART_BASE2,
+   .irq= 74,
+   },
+   { },
+};
+
+static struct platform_device m5206_uart = {
+   .name   = "mcfuart",
+   .id = 0,
+   .dev.platform_data  = m5206_uart_platform,
+};
+
+static struct platform_device *m5206_devices[] __initdata = {
+   _uart,
+};
+
+/***/
+
+static void __init m5206_uart_init_line(int line, int irq)
+{
+   if (line == 0) {
+   writel(MCFSIM_ICR_LEVEL6 | MCFSIM_ICR_PRI1, MCF_MBAR + 
MCFSIM_UART1ICR);
+   writeb(irq, MCFUART_BASE1 + MCFUART_UIVR);
+   mcf_setimr(mcf_getimr() & ~MCFSIM_IMR_UART1);
+   } else if (line == 1) {
+   writel(MCFSIM_ICR_LEVEL6 | MCFSIM_ICR_PRI2, MCF_MBAR + 
MCFSIM_UART2ICR);
+   writeb(irq, MCFUART_BASE2 + MCFUART_UIVR);
+   mcf_setimr(mcf_getimr() & ~MCFSIM_IMR_UART2);
+   }
+}
+
+static void __init m5206_uarts_init(void)
+{
+   const int nrlines = ARRAY_SIZE(m5206_uart_platform);
+   int line;
+
+   for (line = 0; (line < nrlines); line++)
+   m5206_uart_init_line(line, m5206_uart_platform[line].irq);
+}
+
+/***/
+
 void mcf_autovector(unsigned int vec)
 {
volatile unsigned char  *mbar;
@@ -85,7 +135,7 @@ int mcf_timerirqpending(int timer)
 
 /***/
 
-void config_BSP(char *commandp, int size)
+void __init config_BSP(char *commandp, int size)
 {
mcf_setimr(MCFSIM_IMR_MASKALL);
 
@@ -99,3 +149,14 @@ void config_BSP(char *commandp, int size
 }
 
 /***/
+
+static int __init init_BSP(void)
+{
+   m5206_uarts_init();
+   platform_add_devices(m5206_devices, ARRAY_SIZE(m5206_devices));
+   return 0;
+}
+
+arch_initcall(init_BSP);
+
+/***/
-
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/

[M68KNOMMU]: platform setup for 5206 ColdFire UARTs

[Greg Ungerer]

Switch to platform style configuration for 5206 ColdFire UARTs.

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---

diff -Naurp linux-2.6.23-rc1/arch/m68knommu/platform/5206/config.c 
linux-2.6.23-rc1.platform/arch/m68knommu/platform/5206/config.c
--- linux-2.6.23-rc1/arch/m68knommu/platform/5206/config.c  2007-10-25 
10:48:36.0 +1000
+++ linux-2.6.23-rc1.platform/arch/m68knommu/platform/5206/config.c 
2007-10-30 14:18:24.0 +1000
@@ -13,12 +13,12 @@
 #include 
 #include 
 #include 
-#include 
 #include 
+#include 
+#include 
 #include 
-#include 
 #include 
-#include 
+#include 
 
 /***/
 
@@ -38,6 +38,54 @@ unsigned int dma_device_address[MAX_M68K
 
 /***/
 
+static struct mcf_platform_uart m5206_uart_platform[] = {
+   {
+   .mapbase= MCF_MBAR + MCFUART_BASE1,
+   .irq= 73,
+   },
+   {
+   .mapbase= MCF_MBAR + MCFUART_BASE2,
+   .irq= 74,
+   },
+   { },
+};
+
+static struct platform_device m5206_uart = {
+   .name   = "mcfuart",
+   .id = 0,
+   .dev.platform_data  = m5206_uart_platform,
+};
+
+static struct platform_device *m5206_devices[] __initdata = {
+   _uart,
+};
+
+/***/
+
+static void __init m5206_uart_init_line(int line, int irq)
+{
+   if (line == 0) {
+   writel(MCFSIM_ICR_LEVEL6 | MCFSIM_ICR_PRI1, MCF_MBAR + 
MCFSIM_UART1ICR);
+   writeb(irq, MCFUART_BASE1 + MCFUART_UIVR);
+   mcf_setimr(mcf_getimr() & ~MCFSIM_IMR_UART1);
+   } else if (line == 1) {
+   writel(MCFSIM_ICR_LEVEL6 | MCFSIM_ICR_PRI2, MCF_MBAR + 
MCFSIM_UART2ICR);
+   writeb(irq, MCFUART_BASE2 + MCFUART_UIVR);
+   mcf_setimr(mcf_getimr() & ~MCFSIM_IMR_UART2);
+   }
+}
+
+static void __init m5206_uarts_init(void)
+{
+   const int nrlines = ARRAY_SIZE(m5206_uart_platform);
+   int line;
+
+   for (line = 0; (line < nrlines); line++)
+   m5206_uart_init_line(line, m5206_uart_platform[line].irq);
+}
+
+/***/
+
 void mcf_autovector(unsigned int vec)
 {
volatile unsigned char  *mbar;
@@ -88,10 +136,21 @@ int mcf_timerirqpending(int timer)
 
 /***/
 
-void config_BSP(char *commandp, int size)
+void __init config_BSP(char *commandp, int size)
 {
mcf_setimr(MCFSIM_IMR_MASKALL);
mach_reset = coldfire_reset;
 }
 
 /***/
+
+static int __init init_BSP(void)
+{
+   m5206_uarts_init();
+   platform_add_devices(m5206_devices, ARRAY_SIZE(m5206_devices));
+   return 0;
+}
+
+arch_initcall(init_BSP);
+
+/***/
-
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/

[M68KNOMMU]: platform setup for 5249 ColdFire UARTs

[Greg Ungerer]

Switch to platform style configuration for 5249 ColdFire UARTs.

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---

diff -Naurp linux-2.6.23-rc1/arch/m68knommu/platform/5249/config.c 
linux-2.6.23-rc1.platform/arch/m68knommu/platform/5249/config.c
--- linux-2.6.23-rc1/arch/m68knommu/platform/5249/config.c  2007-10-25 
10:48:36.0 +1000
+++ linux-2.6.23-rc1.platform/arch/m68knommu/platform/5249/config.c 
2007-10-30 14:18:24.0 +1000
@@ -12,11 +12,12 @@
 #include 
 #include 
 #include 
-#include 
 #include 
+#include 
+#include 
 #include 
 #include 
-#include 
+#include 
 
 /***/
 
@@ -38,6 +39,54 @@ unsigned int dma_device_address[MAX_M68K
 
 /***/
 
+static struct mcf_platform_uart m5249_uart_platform[] = {
+   {
+   .mapbase= MCF_MBAR + MCFUART_BASE1,
+   .irq= 73,
+   },
+   {
+   .mapbase= MCF_MBAR + MCFUART_BASE2,
+   .irq= 74,
+   }
+};
+
+static struct platform_device m5249_uart = {
+   .name   = "mcfuart",
+   .id = 0,
+   .dev.platform_data  = m5249_uart_platform,
+};
+
+static struct platform_device *m5249_devices[] __initdata = {
+   _uart,
+};
+
+/***/
+
+static void __init m5249_uart_init_line(int line, int irq)
+{
+   if (line == 0) {
+   writel(MCFSIM_ICR_LEVEL6 | MCFSIM_ICR_PRI1, MCF_MBAR + 
MCFSIM_UART1ICR);
+   writeb(irq, MCFUART_BASE1 + MCFUART_UIVR);
+   mcf_setimr(mcf_getimr() & ~MCFSIM_IMR_UART1);
+   } else if (line == 1) {
+   writel(MCFSIM_ICR_LEVEL6 | MCFSIM_ICR_PRI2, MCF_MBAR + 
MCFSIM_UART2ICR);
+   writeb(irq, MCFUART_BASE2 + MCFUART_UIVR);
+   mcf_setimr(mcf_getimr() & ~MCFSIM_IMR_UART2);
+   }
+}
+
+static void __init m5249_uarts_init(void)
+{
+   const int nrlines = ARRAY_SIZE(m5249_uart_platform);
+   int line;
+
+   for (line = 0; (line < nrlines); line++)
+   m5249_uart_init_line(line, m5249_uart_platform[line].irq);
+}
+
+
+/***/
+
 void mcf_autovector(unsigned int vec)
 {
volatile unsigned char  *mbar;
@@ -85,10 +134,21 @@ int mcf_timerirqpending(int timer)
 
 /***/
 
-void config_BSP(char *commandp, int size)
+void __init config_BSP(char *commandp, int size)
 {
mcf_setimr(MCFSIM_IMR_MASKALL);
mach_reset = coldfire_reset;
 }
 
 /***/
+
+static int __init init_BSP(void)
+{
+   m5249_uarts_init();
+   platform_add_devices(m5249_devices, ARRAY_SIZE(m5249_devices));
+   return 0;
+}
+
+arch_initcall(init_BSP);
+
+/***/
-
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]: add configure support for new ColdFire serial driver

[Greg Ungerer]

Add configure support for the new style ColdFire serial driver.

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---

diff -Naurp linux-2.6.23-rc1/drivers/serial/Kconfig 
linux-2.6.23-rc1.platform/drivers/serial/Kconfig
--- linux-2.6.23-rc1/drivers/serial/Kconfig 2007-10-25 10:49:13.0 
+1000
+++ linux-2.6.23-rc1.platform/drivers/serial/Kconfig2007-10-30 
11:20:44.0 +1000
@@ -960,6 +960,30 @@ config SERIAL_COLDFIRE
  This driver supports the built-in serial ports of the Motorola 
ColdFire
  family of CPUs.
 
+config SERIAL_MCF
+   bool "Coldfire serial support (new style driver)"
+   depends on COLDFIRE
+   select SERIAL_CORE
+   help
+ This new serial driver supports the Freescale Coldfire serial ports
+ using the new serial driver subsystem.
+
+config SERIAL_MCF_BAUDRATE
+   int "Default baudrate for Coldfire serial ports"
+   depends on SERIAL_MCF
+   default 19200
+   help
+ This setting lets you define what the default baudrate is for the
+ ColdFire serial ports. The usual default varies from board to board,
+ and this setting is a way of catering for that.
+
+config SERIAL_MCF_CONSOLE
+   bool "Coldfire serial console support"
+   depends on SERIAL_MCF
+   select SERIAL_CORE_CONSOLE
+   help
+ Enable a ColdFire internal serial port to be the system console.
+
 config SERIAL_68360_SMC
bool "68360 SMC uart support"
depends on M68360
-
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]: add build support for new ColdFire serial driver

[Greg Ungerer]

Add build support for the new style ColdFire serial driver.

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---

diff -Naurp linux-2.6.23-rc1/drivers/serial/Makefile 
linux-2.6.23-rc1.platform/drivers/serial/Makefile
--- linux-2.6.23-rc1/drivers/serial/Makefile2007-10-10 06:31:38.0 
+1000
+++ linux-2.6.23-rc1.platform/drivers/serial/Makefile   2007-10-30 
11:19:06.0 +1000
@@ -39,6 +39,7 @@ obj-$(CONFIG_SERIAL_MUX) += mux.o
 obj-$(CONFIG_SERIAL_68328) += 68328serial.o
 obj-$(CONFIG_SERIAL_68360) += 68360serial.o
 obj-$(CONFIG_SERIAL_COLDFIRE) += mcfserial.o
+obj-$(CONFIG_SERIAL_MCF) += mcf.o
 obj-$(CONFIG_V850E_UART) += v850e_uart.o
 obj-$(CONFIG_SERIAL_PMACZILOG) += pmac_zilog.o
 obj-$(CONFIG_SERIAL_LH7A40X) += serial_lh7a40x.o
-
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/

[M68KNOMMU]: use ARRAY_SIZE in ColdFire serial driver

[Greg Ungerer]

Use ARRAY_SIZE macroto get maximum ports in ColdFire serial driver.

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---

diff -Naurp linux-2.6.23-rc1/drivers/serial/mcf.c 
linux-2.6.23-rc1.platform/drivers/serial/mcf.c
--- linux-2.6.23-rc1/drivers/serial/mcf.c   2007-10-25 10:49:13.0 
+1000
+++ linux-2.6.23-rc1.platform/drivers/serial/mcf.c  2007-10-30 
11:18:30.0 +1000
@@ -434,7 +434,7 @@ static struct uart_ops mcf_uart_ops = {
 
 static struct mcf_uart mcf_ports[3];
 
-#defineMCF_MAXPORTS(sizeof(mcf_ports) / sizeof(struct mcf_uart))
+#defineMCF_MAXPORTSARRAY_SIZE(mcf_ports)
 
 //
 #if defined(CONFIG_SERIAL_MCF_CONSOLE)
-
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/

[M68KNOMMU]: use container_of() to access uart struct in Coldfire serial driver

[Greg Ungerer]

Use container_of() to get at uart struct field in port struct
in ColdFire serial driver.

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---

diff -Naurp linux-2.6.23-rc1/drivers/serial/mcf.c 
linux-2.6.23-rc1.platform/drivers/serial/mcf.c
--- linux-2.6.23-rc1/drivers/serial/mcf.c   2007-10-25 10:49:13.0 
+1000
+++ linux-2.6.23-rc1.platform/drivers/serial/mcf.c  2007-10-30 
11:18:30.0 +1000
@@ -69,7 +69,7 @@ static unsigned int mcf_tx_empty(struct 
 
 static unsigned int mcf_get_mctrl(struct uart_port *port)
 {
-   struct mcf_uart *pp = (struct mcf_uart *) port;
+   struct mcf_uart *pp = container_of(port, struct mcf_uart, port);
unsigned long flags;
unsigned int sigs;
 
@@ -87,7 +87,7 @@ static unsigned int mcf_get_mctrl(struct
 
 static void mcf_set_mctrl(struct uart_port *port, unsigned int sigs)
 {
-   struct mcf_uart *pp = (struct mcf_uart *) port;
+   struct mcf_uart *pp = container_of(port, struct mcf_uart, port);
unsigned long flags;
 
spin_lock_irqsave(>lock, flags);
@@ -104,7 +104,7 @@ static void mcf_set_mctrl(struct uart_po
 
 static void mcf_start_tx(struct uart_port *port)
 {
-   struct mcf_uart *pp = (struct mcf_uart *) port;
+   struct mcf_uart *pp = container_of(port, struct mcf_uart, port);
unsigned long flags;
 
spin_lock_irqsave(>lock, flags);
@@ -117,7 +117,7 @@ static void mcf_start_tx(struct uart_por
 
 static void mcf_stop_tx(struct uart_port *port)
 {
-   struct mcf_uart *pp = (struct mcf_uart *) port;
+   struct mcf_uart *pp = container_of(port, struct mcf_uart, port);
unsigned long flags;
 
spin_lock_irqsave(>lock, flags);
@@ -130,7 +130,7 @@ static void mcf_stop_tx(struct uart_port
 
 static void mcf_stop_rx(struct uart_port *port)
 {
-   struct mcf_uart *pp = (struct mcf_uart *) port;
+   struct mcf_uart *pp = container_of(port, struct mcf_uart, port);
unsigned long flags;
 
spin_lock_irqsave(>lock, flags);
@@ -163,7 +163,7 @@ static void mcf_enable_ms(struct uart_po
 
 static int mcf_startup(struct uart_port *port)
 {
-   struct mcf_uart *pp = (struct mcf_uart *) port;
+   struct mcf_uart *pp = container_of(port, struct mcf_uart, port);
unsigned long flags;
 
spin_lock_irqsave(>lock, flags);
@@ -189,7 +189,7 @@ static int mcf_startup(struct uart_port 
 
 static void mcf_shutdown(struct uart_port *port)
 {
-   struct mcf_uart *pp = (struct mcf_uart *) port;
+   struct mcf_uart *pp = container_of(port, struct mcf_uart, port);
unsigned long flags;
 
spin_lock_irqsave(>lock, flags);
@@ -352,7 +352,7 @@ static void mcf_tx_chars(struct mcf_uart
 static irqreturn_t mcf_interrupt(int irq, void *data)
 {
struct uart_port *port = data;
-   struct mcf_uart *pp = (struct mcf_uart *) port;
+   struct mcf_uart *pp = container_of(port, struct mcf_uart, port);
unsigned int isr;
 
isr = readb(port->membase + MCFUART_UISR) & pp->imr;
-
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/

[M68KNOMMU]: use raw read/write for all register access in ColdFire timer

[Greg Ungerer]

Use __raw_read/__raw_write to write to all registers (instead of
using local pointer de-referencing in ColdFirePIT timer code.

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---


diff -Naurp linux-2.6.23/arch/m68knommu/platform/5307/pit.c 
linux-2.6.23-uc0/arch/m68knommu/platform/5307/pit.c
--- linux-2.6.23/arch/m68knommu/platform/5307/pit.c 2007-10-19 
10:30:55.0 +1000
+++ linux-2.6.23-uc0/arch/m68knommu/platform/5307/pit.c 2007-10-19 
10:35:40.0 +1000
@@ -29,6 +29,7 @@
  * By default use timer1 as the system clock timer.
  */
 #defineTA(a)   (MCF_IPSBAR + MCFPIT_BASE1 + (a))
+#defineINTC0   (MCF_IPSBAR + MCFICM_INTC0)
 
 /***/
 
@@ -53,17 +54,14 @@ static struct irqaction coldfire_pit_irq
 
 void hw_timer_init(void)
 {
-   volatile unsigned char *icrp;
-   volatile unsigned long *imrp;
+   u32 imr;
 
setup_irq(MCFINT_VECBASE + MCFINT_PIT1, _pit_irq);
 
-   icrp = (volatile unsigned char *) (MCF_IPSBAR + MCFICM_INTC0 +
-   MCFINTC_ICR0 + MCFINT_PIT1);
-   *icrp = ICR_INTRCONF;
-
-   imrp = (volatile unsigned long *) (MCF_IPSBAR + MCFICM_INTC0 + 
MCFPIT_IMR);
-   *imrp &= ~MCFPIT_IMR_IBIT;
+   __raw_writeb(ICR_INTRCONF, INTC0 + MCFINTC_ICR0 + MCFINT_PIT1);
+   imr = __raw_readl(INTC0 + MCFPIT_IMR);
+   imr &= ~MCFPIT_IMR_IBIT;
+   __raw_writel(imr, INTC0 + MCFPIT_IMR);
 
/* Set up PIT timer 1 as poll clock */
__raw_writew(MCFPIT_PCSR_DISABLE, TA(MCFPIT_PCSR));
-
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/

[M68KNOMMU]: fix pread/pwrite defines

[Greg Ungerer]

Fix system call defines for system call 180 and 181 to match the
underlying system call table function entries. System call 180 calls
sys_pread64, and 181 calls sys_pwrite64, so make the definitions
match.

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---


diff -Naurp linux-2.6.23/include/asm-m68knommu/unistd.h 
linux-2.6.23-uc0/include/asm-m68knommu/unistd.h
--- linux-2.6.23/include/asm-m68knommu/unistd.h 2007-10-19 10:21:31.0 
+1000
+++ linux-2.6.23-uc0/include/asm-m68knommu/unistd.h 2007-10-19 
10:32:28.0 +1000
@@ -185,8 +185,8 @@
 #define __NR_rt_sigtimedwait   177
 #define __NR_rt_sigqueueinfo   178
 #define __NR_rt_sigsuspend 179
-#define __NR_pread 180
-#define __NR_pwrite181
+#define __NR_pread64   180
+#define __NR_pwrite64  181
 #define __NR_lchown182
 #define __NR_getcwd183
 #define __NR_capget184
-
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/

[M68KNOMMU]: cleanup port field access from uart struct in Coldfire serial driver

[Greg Ungerer]

Use port field instead of silly struct/pointer casting to get at
port struct from local uart struct in ColdFire serial driver.

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---

diff -Naurp linux-2.6.23-rc1/drivers/serial/mcf.c 
linux-2.6.23-rc1.platform/drivers/serial/mcf.c
--- linux-2.6.23-rc1/drivers/serial/mcf.c   2007-10-25 10:49:13.0 
+1000
+++ linux-2.6.23-rc1.platform/drivers/serial/mcf.c  2007-10-30 
11:18:30.0 +1000
@@ -273,7 +273,7 @@ static void mcf_set_termios(struct uart_
 
 static void mcf_rx_chars(struct mcf_uart *pp)
 {
-   struct uart_port *port = (struct uart_port *) pp;
+   struct uart_port *port = >port;
unsigned char status, ch, flag;
 
while ((status = readb(port->membase + MCFUART_USR)) & 
MCFUART_USR_RXREADY) {
@@ -319,7 +319,7 @@ static void mcf_rx_chars(struct mcf_uart
 
 static void mcf_tx_chars(struct mcf_uart *pp)
 {
-   struct uart_port *port = (struct uart_port *) pp;
+   struct uart_port *port = >port;
struct circ_buf *xmit = >info->xmit;
 
if (port->x_char) {
-
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] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

[Kazuki Omo(Company)]

Dear, Folks,

Now we are planning to submit LIDS to mainline.
(As you know, it already written for supporing LSM for several years.)

When we will finish to re-write documentation and some FAQ, then
we will be able to submit the patch.

Sincerely,

OMO

Serge E. Hallyn wrote: (2007/10/09 03:00):

Quoting Eric W. Biederman ([EMAIL PROTECTED]):

"Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
Also I'm thinking towards what do we have to do isolate the security
module stuff in the context of a namespace.  So that a person in
a container can setup their own rules that further restrict the
system.


In the selinux example I plan to do set up soon, that will be done
using the '.' namespace separator.

Every object/subject in vserver1 will have a type 'vserver1.whatever'.
'vserver1.root_t', 'vserver1.etc_t', etc.

I don't know how far the policy tools have gotten, but they are
*supposed* to implement constraints at policy compile time such that
every type which is a child of 'vserver1' would have no more access than
what is granted to type 'vserver1'.  So this provides a pretty nice
conceptual way to set up security for a vserver.

Then using the userspace policy server and metapolicy (this would be a
step or two beyond my first example) the policy could define rules about
what sort of policy could be added by a process of type
'vserver1.root_t'.  So we can allow the container admin to introduce
policy changes affecting only his own container, and subject to all
constraints placed by the host admin on vserver1.


So far I'm not ready to do anything yet but I'm keeping a weather eye
on the situation so I have a clue what I'm go.


If 1, an selinux policy should cover you.  So you can then skip to 3.
Or, alternatively, I do plan - as soon as my free time clears up a bit -
on demonstrating how to write some selinux policy to create a secure
container based on current -mm + your experimental network namespace
patches.

Thanks that sounds interesting.


If 3, then selinux policy modules may actually help you, else either
a new LSM (maybe like LIDS) or a userspace tool which is a front-end to
selinux policy, emulating the iptables rules formats, may be what you
want?

I don't want to have to choose my LSM at compile time.  I want to
add support into the kernel at compile time and be able to configure
it before I go multi-user.  I know this kind of architecture is
achievable because iptables allows it.

When I conceive as the security modules as just a firewall between
applications on my own box I think, oh yeah this is no big deal,
I might want to limit something that way some time.  These are just
some additional rules on when to return -EPERM.  So I ask myself why
is this situation much less flexible and much harder to use then our
network firewall code?


It actually used to be far more flexible than it is now.  The consensus
appears to be that it's just too hard - at times impossible - to
properly label every object or subject at some point after they've all
been created (processes created, inodes read from disk, etc).  Two
examples:

1. you've got pid 777.  How was it created?  Can you trust it's
history?  In my DTE module I solved this by keeping track of the
*full* invocation history until a policy was loaded.  I think
tomoyo may do something similar.  But it's really not
sufficient, especially since you don't even want a LSM loaded
at all.  So you can't reduce it to 'boot_t executd init_t
executed login_t executed shell_t', you have to keep track of
every inode executed

2. how do you reliably re-evaluate, for some file, what label
to assign to it?  Do you guess at a pathname?  Do you trust that
the inodes have been pre-labeled for every LSM, so when you load
the LSM you can grab the xattrs?

So it's a valid question - do we address these sorts of concerns in
order to add flexibility, or do we keep things as simple as possible
and say that it's up to the distro, for instance, or a site local
security administrator, to define policy, so that flexibility really
is of very limited use?


My impression is that selinux is one monolithic blob that doesn't
allow me to incrementally add matching or action features that I
find interesting.

Actually with policy modules it gets much much better.  I have in fact
been able to pretty easily write a short policy module to, say, create
an selinux user which ran as root and had full access to the system to
do system setup for automated testing.  There is a learning curve in
having to look at existing modules for maybe a few days to get started,
but once you get started the policy modules do make it very easy to
add to current policy.

Ok. Interesting.  Are these kernel modules?


Policy modules, loaded through selinuxfs at any time using 'semodule'.


Still while I get the general impression that selinux seems to be
very close to a generic solution, and that selinux more or less has

Re: [kvm-devel] [PATCH] raise tsc clocksource rating

[Avi Kivity]

Dan Hecht wrote:
Not really.  In the case hardware TSC is perfect, the paravirt time 
counter can be implemented directly in terms of hardware TSC; there is 
no loss in optimization.  This is done transparently.  And virtual TSC 
can be implemented this way too.


The real improvement that a paravirt clocksource offers over the TSC 
clocksource is that the guest does not need to measure the TSC frequency 
itself against some other constant frequency source (which is 
problematic on a virtual machine).  Instead, the paravirt clocksource 
queries the hypervisor for the frequency of the counter.  As you know, 
with clocksource style kernels, it's important to get this frequency 
correct, or else the guest will have long-term time drift.


  


In addition, a paravirt clocksource can compensate for events like vcpu 
migration to another host cpu.  So I agree: a paravirt clocksource is 
always better than or equal to the tsc.



--
Any sufficiently difficult bug is indistinguishable from a feature.

-
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: USB: FIx locks and urb->status in adutux

[Pete Zaitcev]

On Mon, 29 Oct 2007 20:04:57 +0200, Vitaliy Ivanov <[EMAIL PROTECTED]> wrote:

> Finally had a time on my weekend to perform tests and fix Pete's patch a 
> little. Now it seems to be correct.

Great!

> 1. One device per user space application. Old driver allowed many users 
> application to work with same device which can lead to IO mess.

OK. This trick was popular in UNIX. Personally I think it's in a bad
taste, because good applications still need to verify if only one
instance is running, and threfore can use application level locking.
But if you are gunning for the maintenership I'm not going to argue
your style. The busy lock-out certainly works better than "/dev/cua" :-)

However, this looks wrong:

> +  dev->interrupt_in_endpoint->bInterval);
> + dev->read_urb_finished = 0;
> + retval = usb_submit_urb(dev->interrupt_in_urb, GFP_KERNEL);
> + /* we ignore failure */
> + /* end of fixup for first read */
> +
> + /* initialize out direction */
> + dev->out_urb_finished = 1;

The finished flag is only set when URB is not in use anymore. Did you
observe an anomaly with my code? Any hangs? If so, I assure you this
is not the fix. As it's written, even if we ignore the failure (e.g.
do not pass it to userland), we sill have to maintain the correct
flag state.

-- Pete
-
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: [kvm-devel] 2.6.23.1-rt4 and kvm 48

[Avi Kivity]

David Brown wrote:

Uhm, not sure who to send this too...

I thought I'd try out the realtime patch set and it didn't work at all
with kvm. The console didn't dump anything and the system completely
locked up.

Anyone have any suggestions as to how to get more output on this issue?
  


Make sure CONFIG_PREEMPT_NOTIFIERS is enabled. Jan Kiszka reported 
success with a similar configuration.


--
Any sufficiently difficult bug is indistinguishable from a feature.

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

sata_nv and dynamically changing DMA mask?

[Robert Hancock]

In the sata_nv driver, when running in ADMA mode, we can do 64-bit DMA. 
However, when an ATAPI device like a DVD drive is connected, we can't 
use ADMA mode, and so we have to abide by the restrictions of a normal 
SFF ATA controller and can only do 32-bit DMA. We detect this and try to 
set the blk_queue_bounce_limit, blk_queue_segment_boundary and 
blk_queue_max_hw_segments to the values corresponding to a normal SFF 
controller.


However, we have this bug report:

https://bugzilla.redhat.com/show_bug.cgi?id=351451

that their DVD drive doesn't work properly on a computer with 4GB of RAM 
unless they either disable ADMA (thus resulting in the DMA parameters 
being initialized to the SFF ones from the start) or pass mem=3000M to 
the kernel to keep the memory above the 4GB mark from being used. Thus I 
suspect that what we're trying to do with the DMA parameters is not taking.


Question is: is setting blk_queue_bounce_limit enough to prevent 
addresses outside that mask from showing up, or does the device DMA mask 
also need to be updated? Is there anything wrong with just changing the 
DMA mask at runtime? Keep in mind, ATAPI and non-ATAPI devices can 
potentially be switched out on the port, so the mask might need to be 
updated at runtime..


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

-
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 2/3] Deadline iosched: Reset batch for ordered requests

[Aaron Carroll]

The deadline I/O scheduler does not reset the batch count when starting
a new batch at a higher-sectored request.  This means the second and
subsequent batch in the same data direction will never exceed a single
request in size whenever higher-sectored requests are pending.

This patch gives new batches in the same data direction as old ones
their full quota of requests by resetting the batch count.

Signed-off-by: Aaron Carroll <[EMAIL PROTECTED]>
---
 block/deadline-iosched.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/block/deadline-iosched.c b/block/deadline-iosched.c
index a44437e..cb94c83 100644
--- a/block/deadline-iosched.c
+++ b/block/deadline-iosched.c
@@ -306,12 +306,11 @@ dispatch_writes:
 dispatch_find_request:
/*
 * we are not running a batch, find best request for selected data_dir
+* and start a new batch
 */
if (deadline_check_fifo(dd, data_dir)) {
/* An expired request exists - satisfy it */
-   dd->batching = 0;
rq = rq_entry_fifo(dd->fifo_list[data_dir].next);
-   
} else if (dd->next_rq[data_dir]) {
/*
 * The last req was the same dir and we have a next request in
@@ -325,12 +324,13 @@ dispatch_find_request:
 * higher-sectored requests. Go back to the lowest sectored
 * request (1 way elevator) and start a new batch.
 */
-   dd->batching = 0;
node = rb_first(>sort_list[data_dir]);
if (node)
rq = rb_entry_rq(node);
}
 
+   dd->batching = 0;
+
 dispatch_request:
/*
 * rq is the selected appropriate request.
-
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 3/3] Deadline iosched: Fix batching fairness

[Aaron Carroll]

After switching data directions, deadline always starts the next batch
from the lowest-sector request.  This gives excessive deadline expiries
and large latency and throughput disparity between high- and low-sector
requests; an order of magnitude in some tests.

This patch changes the batching behaviour so new batches start from the
request whose expiry is earliest.

Signed-off-by: Aaron Carroll <[EMAIL PROTECTED]>
---
 block/deadline-iosched.c |   21 +++--
 1 files changed, 7 insertions(+), 14 deletions(-)

diff --git a/block/deadline-iosched.c b/block/deadline-iosched.c
index cb94c83..a054eef 100644
--- a/block/deadline-iosched.c
+++ b/block/deadline-iosched.c
@@ -306,27 +306,20 @@ dispatch_writes:
 dispatch_find_request:
/*
 * we are not running a batch, find best request for selected data_dir
-* and start a new batch
 */
-   if (deadline_check_fifo(dd, data_dir)) {
-   /* An expired request exists - satisfy it */
+   if (deadline_check_fifo(dd, data_dir) || !dd->next_rq[data_dir]) {
+   /*
+* A deadline has expired, the last request was in the other
+* direction, or we have run out of higher-sectored requests.
+* Start again from the request with the earliest expiry time.
+*/
rq = rq_entry_fifo(dd->fifo_list[data_dir].next);
-   } else if (dd->next_rq[data_dir]) {
+   } else {
/*
 * The last req was the same dir and we have a next request in
 * sort order. No expired requests so continue on from here.
 */
rq = dd->next_rq[data_dir];
-   } else {
-   struct rb_node *node;
-   /*
-* The last req was the other direction or we have run out of
-* higher-sectored requests. Go back to the lowest sectored
-* request (1 way elevator) and start a new batch.
-*/
-   node = rb_first(>sort_list[data_dir]);
-   if (node)
-   rq = rb_entry_rq(node);
}
 
dd->batching = 0;
-
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 1/3] Deadline iosched: Factor out finding latter request

[Aaron Carroll]

Factor finding the next request in sector-sorted order into
a function deadline_latter_request.

Signed-off-by: Aaron Carroll <[EMAIL PROTECTED]>
---
 block/deadline-iosched.c |   28 +---
 1 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/block/deadline-iosched.c b/block/deadline-iosched.c
index 1a511ff..a44437e 100644
--- a/block/deadline-iosched.c
+++ b/block/deadline-iosched.c
@@ -55,6 +55,20 @@ static void deadline_move_request(struct deadline_data *, 
struct request *);
 
 #define RQ_RB_ROOT(dd, rq) (&(dd)->sort_list[rq_data_dir((rq))])
 
+/*
+ * get the request after `rq' in sector-sorted order
+ */
+static inline struct request *
+deadline_latter_request(struct request *rq)
+{
+   struct rb_node *node = rb_next(>rb_node);
+
+   if (node)
+   return rb_entry_rq(node);
+
+   return NULL;
+}
+
 static void
 deadline_add_rq_rb(struct deadline_data *dd, struct request *rq)
 {
@@ -74,13 +88,8 @@ deadline_del_rq_rb(struct deadline_data *dd, struct request 
*rq)
 {
const int data_dir = rq_data_dir(rq);
 
-   if (dd->next_rq[data_dir] == rq) {
-   struct rb_node *rbnext = rb_next(>rb_node);
-
-   dd->next_rq[data_dir] = NULL;
-   if (rbnext)
-   dd->next_rq[data_dir] = rb_entry_rq(rbnext);
-   }
+   if (dd->next_rq[data_dir] == rq)
+   dd->next_rq[data_dir] = deadline_latter_request(rq);
 
elv_rb_del(RQ_RB_ROOT(dd, rq), rq);
 }
@@ -198,14 +207,11 @@ static void
 deadline_move_request(struct deadline_data *dd, struct request *rq)
 {
const int data_dir = rq_data_dir(rq);
-   struct rb_node *rbnext = rb_next(>rb_node);
 
dd->next_rq[READ] = NULL;
dd->next_rq[WRITE] = NULL;
+   dd->next_rq[data_dir] = deadline_latter_request(rq);
 
-   if (rbnext)
-   dd->next_rq[data_dir] = rb_entry_rq(rbnext);
-   
dd->last_sector = rq->sector + rq->nr_sectors;
 
/*
-
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 0/3] Deadline iosched: Fix batching algorithm

[Aaron Carroll]

Hi Jens,

The following patches correct some issues with the deadline I/O
scheduler and its batching algorithm.

Patch 1 is a simple function factorisation.
Patch 2 fixes a missing batch count reset, making the behaviour
  closer to that implied by the documentation.
Patch 3 changes batch start points to resolve a disparity in
  latency and bandwidth between high- and low-sector requests.


Thanks,
-- Aaron


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

Kconfig warnings from FEC_MPC52xx

[Gabriel C]

Hi,

I see these warning on my x86_32 box :

..

drivers/net/Kconfig:1887:warning: 'select' used by config symbol 'FEC_MPC52xx' 
refers to undefined symbol 'PPC_BESTCOMM'
drivers/net/Kconfig:1888:warning: 'select' used by config symbol 'FEC_MPC52xx' 
refers to undefined symbol 'PPC_BESTCOMM_FEC'

..

introduced by :

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5d031e9e7e9ad5aa6516646f955c6262478e1acd

Regards,

Gabriel C
-
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: Phis in /proc/bus/input/devices same for all devices?

[Dmitry Torokhov]

Hi Michal,

On Monday 29 October 2007, CIJOML wrote:
> Dne čt 22. února 2007 Dmitry Torokhov napsal(a):
>
> > Plus I
> > will export uniq in /proc/bus/input/devices and then yo can ask X guys
> > to allow matching on uniq as well.
> 
> Hi Dmitri,
> 
> I watched at 2.6.23 and this is still not done yet. Are there any patches 
> available to use???
> 

Input core does export uniq in /proc/bus/input/devices so now it is
up to individual drivers to populate this field in input_dev
structure.

-- 
Dmitry
-
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: tcp rfc 2385 security/bugfix for sparc64

[David Miller]

From: Matthias Dellweg <[EMAIL PROTECTED]>
Date: Tue, 16 Oct 2007 18:47:56 +0200

> while reviewing the tcp_md5-related code further i came across with another
> two of these casts which you probably have missed. I don't actually think
> that they impose a problem by now, but as you said we should remove them.

I'll apply this patch, thanks Matthias.
-
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] Update zfcp_sg_to_address() for new SG chanegs.

[Tony Breeds]

Commit 642f149031d70415d9318b919d50b71e4724adbd Added args to
zfcp_sg_to_address() but didn't update the defn. to know about them.

Signed-off-by: Tony Breeds <[EMAIL PROTECTED]>
---

Only compile tested.

 drivers/s390/scsi/zfcp_def.h |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/s390/scsi/zfcp_def.h b/drivers/s390/scsi/zfcp_def.h
index 0754542..e70cd95 100644
--- a/drivers/s390/scsi/zfcp_def.h
+++ b/drivers/s390/scsi/zfcp_def.h
@@ -70,11 +70,12 @@ zfcp_sg_to_address(struct scatterlist *list)
  * zfcp_address_to_sg - set up struct scatterlist from kernel address
  * @address: kernel address
  * @list: struct scatterlist
+ * @len: buffer length
  */
 static inline void
-zfcp_address_to_sg(void *address, struct scatterlist *list)
+zfcp_address_to_sg(void *address, struct scatterlist *list, unsigned int len)
 {
-   sg_set_buf(list, address, 0);
+   sg_set_buf(list, address, len);
 }
 
 #define REQUEST_LIST_SIZE 128
-- 
1.5.3.4

Yours Tony

  linux.conf.auhttp://linux.conf.au/ || http://lca2008.linux.org.au/
  Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!

-
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: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Toshiharu Harada]

On 10/25/2007 9:41 AM, Chris Wright wrote:

* Linus Torvalds ([EMAIL PROTECTED]) wrote:
Do other people want to stand up and be "LSM maintainers" in the sense 
that they also end up being informed members who can also stand up for new 
modules and help merge them, rather than just push the existing one(s)? 
Chris? Casey? Crispin?


Stephen and James, despite their clear bias towards SELinux, do try to
give good feedback.  But you are right, there's not enough active help
for people trying to make a contribution to get their code in shape.
Many of the modules that come along have been misguided conceptually,
but I think that e.g. apparmor, tomoyo, smack could use that kind
of constructive help to get into final mergable shape.  Personally,
I haven't spent nearly enough time reviewing those, my apologies to
those developers.  So, yes, help is welcome.


Yes, TOMOYO Linux is committed to help.
I mean, please count me in.

PS
Chris, I've been waiting for your comments for our code. :)

Regards,
Toshiharu Harada

-
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: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Toshiharu Harada]

On 10/25/2007 10:42 AM, Casey Schaufler wrote:

I agree that security code does need to provide security. What we
need to get away from is the automatic attacks that are based on 20th
century computer system assumptions. Things like "name based access
control is rediculous", and "a module can't be any good if it doesn't
deal with all objects", or "the granularity isn't fine enough". Look
at TOMOYO. It's chuck full of good ideas. Why spend so much energy
badgering them about not dealing with sockets? How about helping the
AppArmor crew come up with acceptable implementations rather than
whinging about the evils of hard links? And maybe, just maybe, we can
get away from the inevitable claim that you could do that with a few
minutes work in SELinux policy, but only if you're a security
professional of course.


Casey,

Thank you introducing TOMOYO Linux. I really like your idea of
simplified MAC (and you work so hard!). I also find advantages
of AppArmor for distributing policies with less hustle. Finally
and most importantly, I respect SELinux as the first in-tree,
flexible and reliable security frame work and respect developers
involved.

As a project manager of TOMOYO Linux, I would like to
push it, of course. But I noticed, if each of LSM module
developer begin pushing their own code, that's not for the
sake of Linux and we may end up with chaos.

Instead of pushing TOMOYO Linux, I started developing
comparison chart of security-enhance Linux implementations.
The current version can be found in

http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison

I would like to receive feedbacks from Stephen, Crispin
(you already have a comparison, though :),
Casey and any people interested in. If possible,
I would like to include opinions from BSD people.

I would like LSM to be the result of common requirements.
"Common" means good in general, but not always for security
perspective. IMHO, I think it is possible for us to get to the
conclusion not to have a framework.

Cheers (and with love to Linux),
Toshiharu Harada

-
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] Only show RESOURCES_64BIT on relevant architectures

[Kumar Gala]

On Oct 29, 2007, at 9:48 PM, Ralf Baechle wrote:


On Sun, Oct 28, 2007 at 04:15:49PM -0400, Kyle McMartin wrote:


+++ b/mm/Kconfig
@@ -172,6 +172,7 @@ config MIGRATION

 config RESOURCES_64BIT
 	bool "64 bit Memory and IO resources (EXPERIMENTAL)" if (!64BIT  
&& EXPERIMENTAL)

+   depends on (MIPS || PPC32 || X86_PAE) || 64BIT


On MIPS it would be a per platform thing.  I'd prefer if  
RESOURCES_64BIT

was enabled through reverse dependencies and never visible as a user
option.


The same is true on PPC32.  Its a per platform thing.   However, I'm  
not sure if we could hide it from the user.  There are cases on the  
same HW platform that you want to run with just 32-bit phys (for  
performance).


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

[GIT PATCH] ACPI paches for 2.6.24-rc1

[Len Brown]

Hi Linus,

please pull from: 

git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release

This will update the files shown below.

thanks!

-Len

ps. individual patches are available on [EMAIL PROTECTED]
and a consolidated plain patch is available here:
ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.24/acpi-release-20070126-2.6.24-rc1.diff.gz

 Documentation/kernel-parameters.txt |5 
 MAINTAINERS |   18 +-
 drivers/acpi/Kconfig|   10 -
 drivers/acpi/battery.c  |  164 +---
 drivers/acpi/bus.c  |8 -
 drivers/acpi/button.c   |   37 -
 drivers/acpi/ec.c   |  146 ++---
 drivers/acpi/fan.c  |   72 +-
 drivers/acpi/power.c|   63 +++--
 drivers/acpi/sleep/main.c   |5 
 drivers/cpuidle/cpuidle.c   |1 
 drivers/cpuidle/governor.c  |3 
 drivers/misc/fujitsu-laptop.c   |7 -
 include/acpi/acpi_bus.h |3 
 14 files changed, 250 insertions(+), 292 deletions(-)

through these commits:

Adrian Bunk (6):
  ACPI: battery: remove dead code
  ACPI: EC: fix use-after-free
  fujitsu-laptop: make 2 functions static
  cpuidle: unexport tick_nohz_get_sleep_length
  fujitsu-laptop.c: remove dead code
  cpuidle: remove unused exports

Alexey Starikovskiy (16):
  ACPI: sleep: Fix GPE suspend cleanup
  ACPI: suspend: Wrong order of GPE restore.
  ACPI: button: send initial lid state after add and resume
  ACPI: EC: Replace atomic variables with bits
  ACPI: EC: Don't expect interrupt after last read
  ACPI: EC: auto select interrupt mode
  ACPI: EC: Don't re-enable GPE for each transaction.
  ACPI: EC: Add workaround for "optimized" controllers
  ACPI: EC: Output changes to operational mode
  ACPI: power: don't cache power resource state
  ACPI: Fan: fan device does not need own structure
  ACPI: Fan: Drop force_power_state acpi_device option
  ACPI: battery: Update battery information upon sysfs read.
  ACPI: battery: Support for non-spec name for LiIon technology
  ACPI: Battery: Allow extract string from integer
  ACPI: use select POWER_SUPPLY for AC, BATTERY and SBS

Andrey Borzenkov (1):
  ACPI: battery: register power_supply subdevice only when battery is 
present

Frans Pop (1):
  acpi: remove double mention of Support for ACPI option

Len Brown (2):
  ACPI: update MAINTAINERS
  suspend: MAINTAINERS update

with this log:

commit 1942971b20817def5fd1142248307c7c3c51fc8a
Merge: 37e58df... 355ee5e...
Author: Len Brown <[EMAIL PROTECTED]>
Date:   Mon Oct 29 17:31:01 2007 -0400

Pull documentation into release branch

commit 37e58df30063e229ee5157f9d1c1fa1d749917c2
Merge: b2451e4... 83788c0...
Author: Len Brown <[EMAIL PROTECTED]>
Date:   Mon Oct 29 17:30:55 2007 -0400

Pull cpuidle into release branch

commit b2451e4399d7233cd0008823872f51112d18f8d0
Merge: 14f7d72... b023b43...
Author: Len Brown <[EMAIL PROTECTED]>
Date:   Mon Oct 29 17:30:48 2007 -0400

Pull fujitsu into release branch

commit 14f7d720bb6cc60be8931ea1a0f547dc1e475b88
Merge: 6a22c57... 5527c8b...
Author: Len Brown <[EMAIL PROTECTED]>
Date:   Mon Oct 29 17:30:21 2007 -0400

Pull alexey-fixes into release branch

commit 83788c0caed3a425f64fa88fde7c78746b9cdd76
Author: Adrian Bunk <[EMAIL PROTECTED]>
Date:   Mon Oct 29 13:49:13 2007 +0100

cpuidle: remove unused exports

This patch removes the following unused exports:
- cpuidle_devices
- cpuidle_register_governor
- cpuidle_unregister_governor

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>

commit 355ee5eb60e7ce5b5379788c56d36ab162771f7d
Author: Frans Pop <[EMAIL PROTECTED]>
Date:   Mon Oct 29 17:20:38 2007 -0400

acpi: remove double mention of Support for ACPI option

Current description for CONFIG_ACPI includes the word "Support" twice.  One
effect of this is that in menuconfig the "--->" that indicates the presence
of sub-options will not show up unless you have a very wide console.

Signed-off-by: Frans Pop <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>

commit 5527c8bee27fa063dcec0e020fb8c242ba4270c2
Author: Alexey Starikovskiy <[EMAIL PROTECTED]>
Date:   Mon Oct 29 17:08:59 2007 -0400

ACPI: use select POWER_SUPPLY for AC, BATTERY and SBS

POWER_SUPPLY is needed for AC, battery, and SBS sysfs support.  Use
'select' instead of 'depends on', as it is will not be selected by anything
else, leading to confusion.

Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
Tested-by: Frans Pop <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL 

Re: Bootup support for watchdog with short timeout (touch_nmi_watchdog()?)

[Josh Boyer]

On Mon, 29 Oct 2007 15:45:03 -0400
[EMAIL PROTECTED] (Lennart Sorensen) wrote:

> On Mon, Oct 29, 2007 at 03:22:27PM +0100, Stefan Roese wrote:
> > I'm trying to implement support for a board specific watchdog on a 
> > PPC440EPx 
> > board with a very short timeout. In this case, the watchdog has to 
> > be "kicked" at least every 100ms, even while booting and the real watchdog 
> > driver not running yet. While looking for trigger places in the kernel 
> > source, I noticed the already existing "touch_nmi_watchdog()" function, 
> > which 
> > seems to be doing what I need. Even if the name not exactly matches my 
> > hardware setup.
> > 
> > My question now is, is it recommended to use this 
> > touch_nmi_watchdog() "infrastructure" for my PPC custom specific watchdog 
> > during bootup? And if yes, should it perhaps be renamed to a more generic 
> > name, like "touch_watchdog"?
> > 
> > Please advise. Thanks.
> 
> No idea really.  Who would design a watchdog with such a short trigger
> time?  That doesn't seem to be useful in any way.

To some degree, it's configurable.  But the generic question still
stands.  It seems like a decent idea to me.  Making touch_watchdog (or
whatever it winds up being called) nice across arches might be fun.

josh
-
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] Only show RESOURCES_64BIT on relevant architectures

[Ralf Baechle]

On Sun, Oct 28, 2007 at 04:15:49PM -0400, Kyle McMartin wrote:

> +++ b/mm/Kconfig
> @@ -172,6 +172,7 @@ config MIGRATION
>  
>  config RESOURCES_64BIT
>   bool "64 bit Memory and IO resources (EXPERIMENTAL)" if (!64BIT && 
> EXPERIMENTAL)
> + depends on (MIPS || PPC32 || X86_PAE) || 64BIT

On MIPS it would be a per platform thing.  I'd prefer if RESOURCES_64BIT
was enabled through reverse dependencies and never visible as a user
option.

  Ralf
-
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] raise tsc clocksource rating

[Rusty Russell]

On Tuesday 30 October 2007 09:17:38 Thomas Gleixner wrote:
> On Mon, 29 Oct 2007, Glauber de Oliveira Costa wrote:
>
> CC'ed John and removed [EMAIL PROTECTED] :)
>
> > From: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
> >
> > tsc is very good time source (when it does not have drifts, does not
> > change it's frequency, i.e. when it works), so it should have its rating
> > raised to a value greater than, or equal 400.
> >
> > Since it's being a tendency among paravirt clocksources to use values
> > around 400, we should declare tsc as even better: So we use 500.
> >
> > This patch also touches the comments on clocksource.h, which suggests
> > that 499 would be a limit on the rating values.
> >
> > Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
>
> Acked-by: Thomas Gleixner <[EMAIL PROTECTED]>

No.  tsc is very good, it's not perfect.  If a paravirt clock registers 400 it 
really means "pick me over the tsc".

That's *why* they use > 400: it's in the documentation.

Rusty.
-
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: usbserial.ko/option.ko on 2.6.23: Unable to handle kernel paging request && inconsistent lock state

[Greg KH]

On Mon, Oct 29, 2007 at 11:26:31PM +0100, Marcin ?lusarz wrote:
> Hi
> While fighting with Option Globesurfer ICON USB modem I got oops and
> lockdep warning:
> 
> (on rmmod option usbserial, not reproducible)

If you can reproduce this without the nvidia driver loaded, please let
me know.

thanks,

greg k-h
-
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: [RFC] [PATCH] PNP: request ioport and iomem resources used by active devices

[Matthew Garrett]

On Mon, Oct 29, 2007 at 03:25:31PM -0600, Bjorn Helgaas wrote:
> Reserve resources used by active PNP devices to prevent those resources
> from being assigned to other devices.

Yes, I think this is probably a safe approach to take.

-- 
Matthew Garrett | [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/

Re: aim7 -30% regression in 2.6.24-rc1

[Zhang, Yanmin]

On Mon, 2007-10-29 at 17:37 +0800, Zhang, Yanmin wrote:
> On Mon, 2007-10-29 at 10:22 +0800, Zhang, Yanmin wrote:
> > On Fri, 2007-10-26 at 13:23 +0200, Ingo Molnar wrote:
> > > * Zhang, Yanmin <[EMAIL PROTECTED]> wrote:
> > > 
> > > > I tested 2.6.24-rc1 on my x86_64 machine which has 2 quad-core 
> > > > processors.
> > > > 
> > > > Comparing with 2.6.23, aim7 has about -30% regression. I did a bisect 
> > > > and found patch 
> > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b5869ce7f68b233ceb81465a7644be0d9a5f3dbb
> > > >  
> > > > caused the issue.
> > > 
> > > weird, that's a commit diff - i.e. it changes no code.
> > I got the tag from #git log. As for above link, I just added prior http 
> > address,
> > so readers could check the patch by clicking.
> > 
> > > 
> > > > kbuild/SPECjbb2000/SPECjbb2005 also has big regressions. On my another 
> > > > tigerton machine (4 quad-core processors), SPECjbb2005 has more than 
> > > > -40% regression. I didn't do a bisect on such benchmark testing, but I 
> > > > suspect the root cause is like aim7's.
> > > 
> > > these two commits might be relevant:
> > > 
> > >   7a6c6bcee029a978f866511d6e41dbc7301fde4c
> > I did a quick testing. This patch has no impact.
> > 
> > >   95dbb421d12fdd9796ed153853daf3679809274f
> > Above big patch doesn't include this one, which means if I do
> > 'git checkout b5869ce7f68b233ceb81465a7644be0d9a5f3dbb', the kernel doesn't 
> > include
> > 95dbb421d12fdd9796ed153853daf3679809274f.
> > 
> > > 
> > > but a bisection result would be the best info.
> > I will do a bisect between 2.6.23 and tag 
> > 9c63d9c021f375a2708ad79043d6f4dd1291a085.
> I ran git bisect with kernel version as the tag. It looks like git will
> be crazy sometimes. So I checked ChangeLog and used the number tag to replace
> the kernel version and retested it.
> 
> It looks like at least 2 patches were responsible for the regression. I'm
> doing sub-bisect now.
> 
> I could find aim7 regression on all my testing machines although the 
> regression
> percentage is different.
> 
> Machine   regression
> 8-core stoakley   30%
> 16-core tigerton  6%
> tulsa(dual-core+HT, 16 logical cpu)   20%
sub-bisecting captured patch 38ad464d410dadceda1563f36bdb0be7fe4c8938(sched: 
uniform tunings)
caused 20% regression of aim7.

The last 10% should be also related to sched parameters, such like
sysctl_sched_min_granularity.

-yanmin
-
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] raise tsc clocksource rating

[Ian Pratt]

> > Sigh, I don't really want to have this fight again.
> 
> i dont remember us having discussed this before, ever. If there's any
> "fight" about monotonicity and SMP then it would be a pretty onesided
> affair, with you being beaten up seriously ;-)

Actually, it is possible, even for NUMA systems with CPUs running off
completely different oscillators, and in the presence of CPU frequency
changes, power management, and even in the presence of thermal
throttling (though the latter introduces temporary inaccuracies it
doesn't affect monotonicity or rate).

Take a look at the Xen code to see how each physical CPU is
independently calibrated on an ongoing basis, how movement of VCPUs
between physical CPUs is tracked, and how shared variables are used to
ensure montonicity if a guest requires it. 

The fixed-rate TSCs on newer CPUs make some of this stuff easier, but
you still need to cope with different source oscillators and some power
management states.
 
Ian

> > I don't really see what point there is in raising the tsc's rating
> > (why is 300 insufficient again?), but regardless of the value, the
Xen
> > clocksource rating needs to be higher.
> 
> anyway, i agree that this patch cannot go in in its current form.
> 
>   Ingo
> -
> 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/

[patch/rfc 4/4] DaVinci EVM uses pcf857x GPIO driver

[David Brownell]

Declare two of the I2C GPIO expanders to the EVM board init logic, and
use them.  One hooks up to the LEDs using the leds-gpio driver; the other
exposes a switch to sysfs, and initializes the audio clocks.

Oh, and get rid of bogus warning about IDE conflicting with NOR unless
both are actually configured.

---
This is against the DaVinci tree, but this patch will apply to mainline.

 arch/arm/mach-davinci/board-evm.c |  192 ++
 1 files changed, 192 insertions(+)

--- a/arch/arm/mach-davinci/board-evm.c 2007-10-28 21:03:55.0 -0700
+++ b/arch/arm/mach-davinci/board-evm.c 2007-10-29 13:05:40.0 -0700
@@ -13,6 +13,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+
 #include 
 #include 
 #include 
@@ -21,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -167,6 +172,189 @@ static struct platform_device rtc_dev = 
.id = -1,
 };
 
+/*--*/
+
+/*
+ * I2C GPIO expanders
+ */
+
+#define PCF_Uxx_BASE(x)((3 + (x)) * ARCH_GPIOS_PER_CHIP)
+
+
+/* U2 -- LEDs */
+
+static struct gpio_led evm_leds[] = {
+   { .name = "DS8", .active_low = 1,
+   .default_trigger = "heartbeat", },
+   { .name = "DS7", .active_low = 1, },
+   { .name = "DS6", .active_low = 1, },
+   { .name = "DS5", .active_low = 1, },
+   { .name = "DS4", .active_low = 1, },
+   { .name = "DS3", .active_low = 1, },
+   { .name = "DS2", .active_low = 1,
+   .default_trigger = "mmc0", },
+   { .name = "DS1", .active_low = 1,
+   .default_trigger = "ide-disk", },
+};
+
+static const struct gpio_led_platform_data evm_led_data = {
+   .num_leds   = ARRAY_SIZE(evm_leds),
+   .leds   = evm_leds,
+};
+
+static struct platform_device *evm_led_dev;
+
+static int
+evm_led_setup(struct i2c_client *client, int gpio, unsigned ngpio, void *c)
+{
+   struct gpio_led *leds = evm_leds;
+   int status;
+
+   while (ngpio--) {
+   leds->gpio = gpio++;
+   leds++;
+   }
+
+   /* what an extremely annoying way to be forced to handle
+* device unregistration ...
+*/
+   evm_led_dev = platform_device_alloc("leds-gpio", 0);
+   platform_device_add_data(evm_led_dev,
+   _led_data, sizeof evm_led_data);
+
+   evm_led_dev->dev.parent = >dev;
+   status = platform_device_add(evm_led_dev);
+   if (status < 0) {
+   platform_device_put(evm_led_dev);
+   evm_led_dev = NULL;
+   }
+   return status;
+}
+
+static int
+evm_led_teardown(struct i2c_client *client, int gpio, unsigned ngpio, void *c)
+{
+   if (evm_led_dev) {
+   platform_device_unregister(evm_led_dev);
+   evm_led_dev = NULL;
+   }
+   return 0;
+}
+
+static struct pcf857x_platform_data pcf_data_u2 = {
+   .gpio_base  = PCF_Uxx_BASE(0),
+   .setup  = evm_led_setup,
+   .teardown   = evm_led_teardown,
+};
+
+
+/* U18 - A/V clock generator and user switch */
+
+static int sw_gpio;
+
+static ssize_t
+sw_show(struct device *d, struct device_attribute *a, char *buf)
+{
+   char *s = gpio_get_value_cansleep(sw_gpio) ? "on\n" : "off\n";
+
+   strcpy(buf, s);
+   return strlen(s);
+}
+
+static DEVICE_ATTR(user_sw, S_IRUGO, sw_show, NULL);
+
+static int
+evm_u18_setup(struct i2c_client *client, int gpio, unsigned ngpio, void *c)
+{
+   int status;
+
+   /* export dip switch option */
+   sw_gpio = gpio + 7;
+   status = gpio_request(sw_gpio, "user_sw");
+   if (status == 0)
+   status = gpio_direction_input(sw_gpio);
+   if (status == 0)
+   status = device_create_file(>dev, _attr_user_sw);
+   else
+   gpio_free(sw_gpio);
+   if (status != 0)
+   sw_gpio = -EINVAL;
+
+   /* audio PLL:  48 kHz (vs 44.1 or 32), single rate (vs double) */
+   gpio_request(gpio + 3, "pll_fs2");
+   gpio_direction_output(gpio + 3, 0);
+
+   gpio_request(gpio + 2, "pll_fs1");
+   gpio_direction_output(gpio + 2, 0);
+
+   gpio_request(gpio + 1, "pll_sr");
+   gpio_direction_output(gpio + 1, 0);
+
+   return 0;
+}
+
+static int
+evm_u18_teardown(struct i2c_client *client, int gpio, unsigned ngpio, void *c)
+{
+   gpio_free(gpio + 1);
+   gpio_free(gpio + 2);
+   gpio_free(gpio + 3);
+
+   if (sw_gpio > 0) {
+   device_remove_file(>dev, _attr_user_sw);
+   gpio_free(sw_gpio);
+   }
+   return 0;
+}
+
+static struct pcf857x_platform_data pcf_data_u18 = {
+   .gpio_base  = PCF_Uxx_BASE(1),
+   .n_latch= (1 << 3) | (1 << 2) | (1 << 1),
+   .setup  = evm_u18_setup,
+   .teardown   = evm_u18_teardown,
+};
+
+
+/* U35 - various I/O signals used to manage USB, CF, ATA, etc */
+

[patch/rfc 3/4] DaVinci platform uses new GPIOLIB

[David Brownell]

Switch DaVinci over to using the new GPIO library, so it can access
GPIO expanders and other non-SOC GPIOs using the same calls.
---
This is an example conversion, against the current DaVinci tree
(it probably won't apply against mainline).  The header changes
mostly by what it wraps, and allowing a broader range of GPIOs.
The implementation code is a it simpler, since it no longer needs
to map GPIO numbers to register banks by itself.  It's fairly
representative of what most platform conversions would look like,
except that many platforms won't actually inline access to any
of the SOC-native GPIO signals.

 arch/arm/Kconfig|2 
 arch/arm/mach-davinci/gpio.c|  137 +++-
 include/asm-arm/arch-davinci/gpio.h |   63 +++-
 3 files changed, 105 insertions(+), 97 deletions(-)

--- a/arch/arm/Kconfig  2007-10-27 08:50:31.0 -0700
+++ b/arch/arm/Kconfig  2007-10-27 08:50:31.0 -0700
@@ -396,9 +396,11 @@ config ARCH_DAVINCI
select GENERIC_TIME
select GENERIC_CLOCKEVENTS
select GENERIC_GPIO
+   select GPIO_LIB
help
  Support for TI's DaVinci platform.
 
+
 config ARCH_OMAP
bool "TI OMAP"
select GENERIC_GPIO
--- a/arch/arm/mach-davinci/gpio.c  2007-10-27 08:50:22.0 -0700
+++ b/arch/arm/mach-davinci/gpio.c  2007-10-27 13:57:01.0 -0700
@@ -1,7 +1,7 @@
 /*
  * TI DaVinci GPIO Support
  *
- * Copyright (c) 2006 David Brownell
+ * Copyright (c) 2006-2007 David Brownell
  * Copyright (c) 2007, MontaVista Software, Inc. <[EMAIL PROTECTED]>
  *
  * This program is free software; you can redistribute it and/or modify
@@ -26,47 +26,45 @@
 
 #include 
 
-static DEFINE_SPINLOCK(gpio_lock);
-static DECLARE_BITMAP(gpio_in_use, DAVINCI_N_GPIO);
-
-int gpio_request(unsigned gpio, const char *tag)
-{
-   if (gpio >= DAVINCI_N_GPIO)
-   return -EINVAL;
 
-   if (test_and_set_bit(gpio, gpio_in_use))
-   return -EBUSY;
+static DEFINE_SPINLOCK(gpio_lock);
 
-   return 0;
-}
-EXPORT_SYMBOL(gpio_request);
+struct davinci_gpio {
+   struct gpio_chipchip;
+   struct gpio_controller  *__iomem regs;
+};
 
-void gpio_free(unsigned gpio)
-{
-   if (gpio >= DAVINCI_N_GPIO)
-   return;
+static struct davinci_gpio chips[DIV_ROUND_UP(DAVINCI_N_GPIO, 32)];
 
-   clear_bit(gpio, gpio_in_use);
-}
-EXPORT_SYMBOL(gpio_free);
 
 /* create a non-inlined version */
-static struct gpio_controller *__iomem gpio2controller(unsigned gpio)
+static struct gpio_controller *__iomem __init gpio2controller(unsigned gpio)
 {
return __gpio_to_controller(gpio);
 }
 
+
+/*--*/
+
 /*
- * Assuming the pin is muxed as a gpio output, set its output value.
+ * board setup code *MUST* set PINMUX0 and PINMUX1 as
+ * needed, and enable the GPIO clock.
  */
-void __gpio_set(unsigned gpio, int value)
+
+static int davinci_direction_in(struct gpio_chip *chip, unsigned offset)
 {
-   struct gpio_controller *__iomem g = gpio2controller(gpio);
+   struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
+   struct gpio_controller *__iomem g = d->regs;
+   u32 temp;
 
-   __raw_writel(__gpio_mask(gpio), value ? >set_data : >clr_data);
-}
-EXPORT_SYMBOL(__gpio_set);
+   spin_lock(_lock);
+   temp = __raw_readl(>dir);
+   temp |= (1 << offset);
+   __raw_writel(temp, >dir);
+   spin_unlock(_lock);
 
+   return 0;
+}
 
 /*
  * Read the pin's value (works even if it's set up as output);
@@ -75,61 +73,74 @@ EXPORT_SYMBOL(__gpio_set);
  * Note that changes are synched to the GPIO clock, so reading values back
  * right after you've set them may give old values.
  */
-int __gpio_get(unsigned gpio)
+static int davinci_gpio_get(struct gpio_chip *chip, unsigned offset)
 {
-   struct gpio_controller  *__iomem g = gpio2controller(gpio);
+   struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
+   struct gpio_controller *__iomem g = d->regs;
 
-   return !!(__gpio_mask(gpio) & __raw_readl(>in_data));
+   return !!((1 << offset) & __raw_readl(>in_data));
 }
-EXPORT_SYMBOL(__gpio_get);
-
 
-/*--*/
-
-/*
- * board setup code *MUST* set PINMUX0 and PINMUX1 as
- * needed, and enable the GPIO clock.
- */
-
-int gpio_direction_input(unsigned gpio)
+static int
+davinci_direction_out(struct gpio_chip *chip, unsigned offset, int value)
 {
-   struct gpio_controller  *__iomem g = gpio2controller(gpio);
-   u32 temp;
-   u32 mask;
-
-   if (!g)
-   return -EINVAL;
+   struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
+   struct gpio_controller *__iomem g = d->regs;
+   u32 temp;
+   u32 mask = 1 << offset;
 

[patch/rfc 2/4] pcf875x I2C GPIO expander driver

[David Brownell]

This is a new-style I2C driver for some common 8 and 16 bit I2C based
GPIO expanders:  pcf8574 and pcf8575.  Since it's a new-style driver,
it's configured as part of board-specific init ... eliminating the
need for error-prone manual configuration of module parameters.

The driver exposes the GPIO signals using the platform-neutral GPIO
programming interface, so they are easily accessed by other kernel
code.  The lack of such a flexible kernel API is what has ensured
the proliferation of board-specific hacks for these chips... stuff
that rarely makes it upstream since it's so ugly.  This driver will
let such board-specific code use standard GPIO calls.

Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
Note that there's currently a drivers/i2c/chips/pcf8574.c driver.

Key differences include:  this one talks to other kernel code so
it can use the GPIOs "normally", but that one talks to userspace
through sysfs.  Also, this one is a "new style" I2C driver, so it's
smaller and doesn't need all those error-prone module parameters.
Plus, this one handles both 8 and 16 bit chip versions.

 drivers/i2c/chips/Kconfig   |   18 ++
 drivers/i2c/chips/Makefile  |1 
 drivers/i2c/chips/pcf857x.c |  309 
 include/linux/pcf857x.h |   43 ++
 4 files changed, 371 insertions(+)

--- a/drivers/i2c/chips/Kconfig 2007-10-28 21:04:06.0 -0700
+++ b/drivers/i2c/chips/Kconfig 2007-10-29 14:16:01.0 -0700
@@ -51,6 +51,24 @@ config SENSORS_EEPROM
  This driver can also be built as a module.  If so, the module
  will be called eeprom.
 
+config GPIO_PCF857X
+   tristate "PCF875x GPIO expanders"
+   depends on GPIO_LIB
+   help
+ Say yes here to provide access to some I2C GPIO expanders which
+ may be used for additional digital outputs or inputs:
+
+   - pcf8574, pcf8574a ... 8 bits, from NXP or TI
+   - pcf8575, pcf8575c ... 16 bits, from NXP or TI
+
+ Your board setup code will need to declare the expanders in
+ use, and assign numbers to the GPIOs they expose.  Those GPIOs
+ can then be used from drivers and other kernel code, just like
+ other GPIOs, but only accessible from task contexts.
+
+ This driver provides only an in-kernel interface to those GPIOs.
+ Any sysfs interface to userspace would be provided separately.
+
 config SENSORS_PCF8574
tristate "Philips PCF8574 and PCF8574A"
depends on EXPERIMENTAL
--- /dev/null   1970-01-01 00:00:00.0 +
+++ b/include/linux/pcf857x.h   2007-10-28 21:09:49.0 -0700
@@ -0,0 +1,43 @@
+#ifndef __LINUX_PCF857X_H
+#define __LINUX_PCF857X_H
+
+/**
+ * struct pcf857x_platform_data - data to set up pcf857x driver
+ * @gpio_base: number of the chip's first GPIO
+ * @n_latch: optional bit-inverse of initial output state
+ * @context: optional parameter passed to setup() and teardown()
+ * @setup: optional callback issued once the GPIOs are valid
+ * @teardown: optional callback issued before the GPIOs are invvalidated
+ *
+ * In addition to the I2C_BOARD_INFO() state appropriate to each chip,
+ * the i2c_board_info used with the pcf875x driver must provide the
+ * chip "type" ("pcf8574", "pcf8574a", "pcf8575", "pcf8575c") and its
+ * platform_data (pointer to one of these structures) with at least
+ * the gpio_base value initialized.
+ *
+ * The @setup callback may be used with the kind of board-specific glue
+ * which hands the (now-valid) GPIOs to other drivers, or which puts
+ * devices in their initial states using these GPIOs.
+ *
+ * Since these GPIO chips don't have conventional registers recording
+ * whether a pin is used for input or output, or an output latch to
+ * record the values being driven, the n_latch value may be used to
+ * avoid intialization glitches.  Its inverted value initializes the
+ * value into which bits are masked before they're written to the PCF
+ * chip.  That means that if it's left at zero, the chip is treated as
+ * if it came from power-up reset.
+ */
+struct pcf857x_platform_data {
+   unsignedgpio_base;
+   unsignedn_latch;
+
+   void*context;
+   int (*setup)(struct i2c_client *client,
+   int gpio, unsigned ngpio,
+   void *context);
+   int (*teardown)(struct i2c_client *client,
+   int gpio, unsigned ngpio,
+   void *context);
+};
+
+#endif /* __LINUX_PCF857X_H */
--- a/drivers/i2c/chips/Makefile2007-10-28 21:04:06.0 -0700
+++ b/drivers/i2c/chips/Makefile2007-10-28 21:09:49.0 -0700
@@ -11,6 +11,7 @@ obj-$(CONFIG_SENSORS_M41T00)  += m41t00.o
 obj-$(CONFIG_SENSORS_PCA9539)  += pca9539.o
 obj-$(CONFIG_SENSORS_PCF8574)  += pcf8574.o
 obj-$(CONFIG_SENSORS_PCF8591)  += pcf8591.o

[patch/rfc 1/4] GPIO implementation framework

[David Brownell]

Provides new implementation infrastructure that platforms may choose to use
when implementing the GPIO programming interface.  Platforms can update their
GPIO support to use this.  The downside is slower access to non-inlined GPIOs;
rarely a problem except when bitbanging some protocol.  The upside is:

  * Providing two features which were "want to have (but OK to defer)" when
GPIO interfaces were first discussed in November 2006:

-   A "struct gpio_chip" to plug in GPIOs that aren't directly supported
by SOC platforms, but come from FPGAs or other multifunction devices
(like UCB-1x00 GPIOs).

-   Full support for message-based GPIO expanders, needing a gpio_chip
hookup; previous support for this part of the programming interface
was just stubs.  (One example: the widely used pcf8574 I2C chips,
with 8 GPIOs each.)

  * Including a non-stub implementation of the gpio_{request,free}() calls,
which makes those calls much more useful.  The diagnostic labels are
also recorded given DEBUG_FS, so /sys/kernel/debug/gpio can show a
snapshot of all GPIOs known to this infrastructure.

The driver programming interfaces introduced in 2.6.21 do not change at all;
this new infrastructure is entirely below the covers.

One open issue is how to handle IRQs reported through GPIO expanders.  For
example, I2C chips may be able to report IRQs, but the genirq framework
won't much like the need to manage them in can-sleep contexts or the way
their irq_chip structures can be removed.

This opens the door to an augmented programming interface, addressing GPIOs
by chip and index.  That could be used as a performance tweak (lookup once
and cache, avoiding locking and lookup overheads) or to support transient
GPIOs which aren't registered in the integer GPIO namespace (a USB-to-GPIO
adapter, GPIOs coupled to some other type of add-on card, etc).

Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
 Documentation/gpio.txt |   12 -
 include/asm-generic/gpio.h |  127 +++
 lib/Kconfig|6 
 lib/Makefile   |2 
 lib/gpiolib.c  |  500 +
 5 files changed, 644 insertions(+), 3 deletions(-)

--- a/Documentation/gpio.txt2007-10-29 01:27:23.0 -0700
+++ b/Documentation/gpio.txt2007-10-29 01:30:02.0 -0700
@@ -63,7 +63,9 @@ and that can be critical for glue logic.
 Plus, this doesn't define an implementation framework, just an interface.
 One platform might implement it as simple inline functions accessing chip
 registers; another might implement it by delegating through abstractions
-used for several very different kinds of GPIO controller.
+used for several very different kinds of GPIO controller.  (There is some
+library code supporting such an implementation strategy, but drivers using
+the interface should not care if that's how the interface is implemented.)
 
 That said, if the convention is supported on their platform, drivers should
 use it when possible.  Platforms should declare GENERIC_GPIO support in
@@ -223,6 +225,9 @@ Note that requesting a GPIO does NOT cau
 way; it just marks that GPIO as in use.  Separate code must handle any
 pin setup (e.g. controlling which pin the GPIO uses, pullup/pulldown).
 
+Also note that it's your responsibility to have stopped using a GPIO
+before you free it.
+
 
 GPIOs mapped to IRQs
 
@@ -238,7 +243,7 @@ map between them using calls like:
 
 Those return either the corresponding number in the other namespace, or
 else a negative errno code if the mapping can't be done.  (For example,
-some GPIOs can't used as IRQs.)  It is an unchecked error to use a GPIO
+some GPIOs can't be used as IRQs.)  It is an unchecked error to use a GPIO
 number that wasn't set up as an input using gpio_direction_input(), or
 to use an IRQ number that didn't originally come from gpio_to_irq().
 
@@ -299,6 +304,7 @@ Related to multiplexing is configuration
 pulldowns integrated on some platforms.  Not all platforms support them,
 or support them in the same way; and any given board might use external
 pullups (or pulldowns) so that the on-chip ones should not be used.
+(When a circuit needs 5 kOhm, on-chip 100 kOhm resistors won't do.)
 
 There are other system-specific mechanisms that are not specified here,
 like the aforementioned options for input de-glitching and wire-OR output.
@@ -312,4 +318,4 @@ Dynamic definition of GPIOs is not curre
 a side effect of configuring an add-on board with some GPIO expanders.
 
 These calls are purely for kernel space, but a userspace API could be built
-on top of it.
+on top of them.
--- a/lib/Kconfig   2007-10-29 01:27:23.0 -0700
+++ b/lib/Kconfig   2007-10-29 01:30:02.0 -0700
@@ -141,4 +141,10 @@ config HAS_DMA
 config CHECK_SIGNATURE
bool
 
+#
+# gpiolib is selected if needed
+#
+config GPIO_LIB
+   boolean
+
 endmenu
--- 

[patch/rfc 0/4] GPIO implementation framework

[David Brownell]

When we hashed out the Documentation/gpio.txt GPIO programming
interfaces last year, there were a few features in the "we want
this eventually, but can live without it for now" category.
Following this post are patches adding some of those features.

Two core patches are:

 - Implementation framework in lib/gpiolib.c ... the interface
   provided to GPIO _users_ is unchanged, but providers can now
   hook up through a "gpio_chip" that lets multiple types of
   GPIO provider coexist.  Examples:  SOC-native GPIOs, ones
   provided by an FPGA, I2C or SPI GPIO expanders, etc.

   (I'm thinking this is pretty much ready to merge into MM,
   unless someone turns up a blocking issue...)

 - I2C driver for common pcf8574/8575 GPIO expanders ... these
   are pretty common on embedded hardware, and it's routine for
   external trees to have ugly board-specific hacks exposing
   those GPIOs to drivers.  Unlike such hacks, I think support
   using standard GPIO calls should be mergable upstream.

   (IMO this is ready to merge too, although I know Jean would
   like additional infrastructure which could let us obsolete
   existing drivers, instead of just offering an alternative for
   systems that need kernel access instead of userspace access.)

Two more patches show how they can be used:

 - Platform conversion for DaVinci ... making the SOC-native
   GPIOs plug in through gpiolib instead of directly, except
   when callers can leverage the inline optimization.

 - Board conversion (partial) for DaVinci EVM ... exposing
   the LEDs hooked up to one pcf8574a chip using leds-gpio,
   along with the A/V clocks (and a random user switch) on
   another pcf chip.  A third pcf chip isn't converted; it'd
   mean changing half a dozen drivers, none of which are yet
   upstream.

If the gpiolib patch merges into MM, then I think it'd be
realistic to expect some platforms and boards to be using
this new infrastructure in 2.6.25 ...

- Dave

-
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: [RFC] Create instrumentation directory (git repository)

[Mathieu Desnoyers]

* Jeff Garzik ([EMAIL PROTECTED]) wrote:
> Mathieu Desnoyers wrote:
> >I see no good reason to have so many different adhoc instrumentation
> >mechanisms for profiling (sched, vm, oprofile) and tracing (blktrace,
> >suspend/resume tracing) all over the place. Merging them in a single
> >directory seems like a good step towards a more generic
> >instrumentation/profiling/tracing infrastructure.
> 
> Moving files about in directories should be at the /lowest/ end of the 
> priority scale.  It makes diffs unreadable, file histories and diffing 
> difficult, and a host of other problems.
> 
> Please solve the /real/ problems, and then come back and clean up the 
> file structure after that is done.  Massive file renaming to satisfying 
> some imagined future everything-is-golden scheme is the /last/ step.  It 
> is the last step taken because the previous steps inevitably give you 
> guidance that you otherwise would not have had at the start of the task.
> 
> When I try to diff between old and new alpha oprofile code, I really 
> want to know that the reason why diffing is a pain in the ass is more 
> than "it seemed like a good first step."
> 

And how is this confirmed by the way the i386-x86_64 -> x86 merge is
done ? It seems like a good current counter-example of what you just
affirmed.

First organizing the functionally similar existing code into a single
placeholder will just help finding code duplication, just like two very
similar architectures such as i386 and x86_64.

Talking about solving "real" problems, this is what I have been working
on for about 3 years in the kernel tracing area, writing the LTTng
tracer. What I see at this point is that there is a strong interest for
collaboration between the instrumentation projects (LTTng, SystemTAP,
DTI), but since the code ends up being sprinkled all across the kernel,
it's rather hard to spot duplicates. Actually, I just ran into Linus's
suspend/resume tracer _today_.

Talking about solving real problems, this is also what I did with the
Linux Kernel Markers patch, which can now be used to instrument the
kernel code. But it only deals with one aspect of instrumentation: the
markup itself.

I would categorize what we need for instrumentation in the following
categories :

- Data identification
  * static markup, enabled dynamically, very low impact
  * dynamic markup
  * oprofile (especially for the performance counters)
  * stack traces
- Control
  * Tracing management
  * Profiling management
  * PMC management
- Data extraction
  * relay
  * debugfs
  * serial port output
  * LKCD

What I consider to fit into the instrumentation directory is the data
identification and the control mechanisms. The data extraction should be
done be generic pieces of infrastructure already present in the kernel.

Your suggestion of "first fixing the real problems" (do you mean by
this : add new code ?) and later bother about the file structure just
seems to go against most suggestions I have received from kernel
developers in the past years. Getting something new in the kernel is
much more straightforward if someone is willing to first clean up the
mess (I am quoting Thomas Gleixner here).  So, in this particular case,
addressing the real problem : people out there want a tracer in the
Linux kernel, will first require to clean up the currently existing
mess : overlapping instrumentation code sprinkled all over the place.


> 
> >Back to "profile" and "probes" directory names, they might be short, but
> >they do not represent the whole markup-profiling-tracing trio,
> >"profile" lacks the tracing part and "probe" lacks the markup part.
> 
> You can always add more letters (and words) to even reach the desired 
> level of specificity.  That does nothing to help readability though.
> 
> Anyway, it should be clear from existing precedent -- existing pathnames 
> -- that "instrumentation" is too long, and really IMO too vague anyway.
> 

I guess you don't use the Documentation/ directory often then. ;)

How about i13n ? :) Jokes aside, I could live with "probe", although it
doesn't fit the purpose exactly. Getting the perfect name, to me, come
second after the need to group those files.

Mathieu


-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
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 maple bus compiler warning

[Paul Mundt]

On Sun, Oct 28, 2007 at 02:24:10PM +, Adrian McMenamin wrote:
> The API for uevent has changed for 2.6.24 and this patch makes a
> consequential clean up.
> 
> (Apols to linux-sh list users seeing this for the second time, I
> should have included lkml first time round for completeness)
> 
> Signed-off-by: Adrian McMenamin <[EMAIL PROTECTED]>
> 
Applied, thanks.
-
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] raise tsc clocksource rating

[john stultz]

On Mon, 2007-10-29 at 23:17 +0100, Thomas Gleixner wrote:
> On Mon, 29 Oct 2007, Glauber de Oliveira Costa wrote:
> 
> CC'ed John and removed [EMAIL PROTECTED] :)
> 
> > From: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
> > 
> > tsc is very good time source (when it does not have drifts, does not
> > change it's frequency, i.e. when it works), so it should have its rating
> > raised to a value greater than, or equal 400.

But all of those qualities (and more) make it less then ideal.

What issue exactly does this patch resolve?

> > Since it's being a tendency among paravirt clocksources to use values
> > around 400, we should declare tsc as even better: So we use 500.

This is the rating inflation I was initially worried about and created
the advisory scale to avoid. If paravirt clocksources are rated too
high, they should be dropped. 

I strongly disagree that the TSC is a "perfect" clocksource, and I think
its rating is appropriate. 


> > This patch also touches the comments on clocksource.h, which suggests
> > that 499 would be a limit on the rating values.
> > 
> > Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
> 
> Acked-by: Thomas Gleixner <[EMAIL PROTECTED]>

If a better justification can be provided, I might reconsider, but right
now I can't ack this.

thanks
-john

> > ---
> >  arch/x86/kernel/tsc_32.c|2 +-
> >  arch/x86/kernel/tsc_64.c|2 +-
> >  include/linux/clocksource.h |2 +-
> >  3 files changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/x86/kernel/tsc_32.c b/arch/x86/kernel/tsc_32.c
> > index 9ebc0da..4d91e59 100644
> > --- a/arch/x86/kernel/tsc_32.c
> > +++ b/arch/x86/kernel/tsc_32.c
> > @@ -280,7 +280,7 @@ static cycle_t read_tsc(void)
> >  
> >  static struct clocksource clocksource_tsc = {
> > .name   = "tsc",
> > -   .rating = 300,
> > +   .rating = 500,
> > .read   = read_tsc,
> > .mask   = CLOCKSOURCE_MASK(64),
> > .mult   = 0, /* to be set */
> > diff --git a/arch/x86/kernel/tsc_64.c b/arch/x86/kernel/tsc_64.c
> > index 9c70af4..4fd5b1b 100644
> > --- a/arch/x86/kernel/tsc_64.c
> > +++ b/arch/x86/kernel/tsc_64.c
> > @@ -262,7 +262,7 @@ static cycle_t __vsyscall_fn vread_tsc(void)
> >  
> >  static struct clocksource clocksource_tsc = {
> > .name   = "tsc",
> > -   .rating = 300,
> > +   .rating = 500,
> > .read   = read_tsc,
> > .mask   = CLOCKSOURCE_MASK(64),
> > .shift  = 22,
> > diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
> > index 107787a..5b0aadd 100644
> > --- a/include/linux/clocksource.h
> > +++ b/include/linux/clocksource.h
> > @@ -39,7 +39,7 @@ struct clocksource;
> >   * A correct and usable clocksource.
> >   * 300-399: Desired.
> >   * A reasonably fast and accurate clocksource.
> > - * 400-499: Perfect
> > + * >= 400 : Perfect
> >   * The ideal clocksource. A must-use where
> >   * available.
> >   * @read:  returns a cycle value
> > -- 
> > 1.5.0.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/
> > 

-
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: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23

[Jaya Kumar]

On 10/29/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> [ also, remap_vmalloc_range() suffers similar issues, only file and anon
>   have proper rmap ]
>
> I'm not sure we want full rmap for remap_pfn/vmalloc_range, but perhaps
> we could assist drivers in maintaining and using vma lists.
>
> I think page_mkclean_one() would work if you'd manually set page->index
> and iterate the vmas yourself. Although atm I'm not sure of anything so
> don't pin me on it.

:-) If it's anybody's fault, it's mine for not testing properly. My bad.

In the case of defio, I think it's no trouble to build a list of vmas
at mmap time and then to iterate through them when it's ready for
mkclean time as you suggested. I don't fully understand page->index
yet. I had thought it was only used by swap cache or file map.

On an unrelated note, I was looking for somewhere to stuff a 16 bit
offset (so that I have a cheap way to know which struct page
corresponds to which framebuffer block or offset) for another driver.
I had thought page->index was it but I think I am wrong now.

Thanks,
jaya
-
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: Out-of-tree modules [was: Linux Security *Module* Framework]

[Jan Engelhardt]

On Oct 29 2007 20:46, Lee Revell wrote:
>On 10/29/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>> quad_dsp - http://jengelh.hopto.org/p/quad_dsp/
>>
>> Provides a /dev/dsp style node for legacy applications that support
>> neither ALSA nor the AOSS wrapper nor more-than-2-channel sound.
>>
>
>(I think that should read "AND more than 2 channel sound")

It is for programs that only give out 2 channels of audio data.
Qdsp_dpl2 is a node that applies the DPL2 matrix on these two channels,
yielding the rear 2 channels, giving some sort of surround effect.

>Couldn't ALSA's OSS emulation be extended to support more than 2
>channels per device node?

I figured that exceeded my skills at that time.

>> thkd - 
>> ftp://ftp5.gwdg.de/pub/linux/misc/suser-jengelh/kernel/linux-2.6.23.1-ccj58/thkd.diff
>>
>> Workaround for Toshiba MK2003GAH hard-drive head auto-unloading after
>> 5-15 seconds. (Ref: http://lkml.org/lkml/2006/11/15/100 )
>
>It looks like this could be trivially fixed in a mergeable way.  That
>LKML thread petered out before the problem was seriously analyzed.
>
>Did you try the -Z flag of hdparm?

IIRC, yes, been through all sorts of hdparm options. -Z did not help
at all, and -B only prolonged the delay from 5 to around 15 seconds.
I contacted Tosh Corp (before posting on lkml) and while they know of
the 'issue', I did not get a satisfactory answer (namely how to FIX
it), so I thought why spend time slapping if there's a workaround...

Causing a minimal head seek every now and then (4096 bytes per 3
seconds is a somewhat small block size with a not-too-low interval)
is a working workaround for now. The module code is not top notch,
but I doubt I'll ever have more than one 1.8" MK2003GAH disk in the
same laptop.
-
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] Revert x86: add lapic_shutdown for x86_64

[Thomas Gleixner]

On Mon, 29 Oct 2007, Hiroshi Shimamoto wrote:

> Arjan van de Ven wrote:
> > On Mon, 29 Oct 2007 15:39:46 -0700
> > Hiroshi Shimamoto <[EMAIL PROTECTED]> wrote:
> > 
> >> lapic_shutdown is useless on x86_64.
> >>
> > 
> >  but since the goal is to get apic_32.c and apic_64.c to be more
> > converging (to the point of becoming the same file)... isn't your patch
> > going in the opposite direction?
> > 
> Hmm, I'm not sure that this revert affects x86 unification.
> Vivek said that probably we don't have to introduce lapic_shutdown() for 
> 64bit.
> So I submitted this patch which reverts my previous post, it was applied 
> before
> the comment.

Don't worry, we sort this out. There is some inevitable friction loss
for now, but we are getting closer. I gave the apic code some care to
get a readable diff out of it. Result is in:

git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git cleanup

Thanks,

tglx
-
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: [RFC] Create instrumentation directory (git repository)

[Jeff Garzik]

Mathieu Desnoyers wrote:

Putting stuff in instrumentation/ by no way means that it becomes
optional for a subsystem, but merely that it could either export
information useful for kernel instrumentation or have some
infrastructure parts merged with others. 


More reason why you should not be moving stuff all around the tree...

Really, file structure is one of the LEAST important issues around -- 
while moving files around introduces a non-zero amount of pain.


New files -- like that godawful and nearly empty samples/ directory -- 
sure, fix that up before release.  But let's not break diffs of existing 
architectures without good reason.


Jeff


-
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: [RFC] Create instrumentation directory (git repository)

[Jeff Garzik]

Mathieu Desnoyers wrote:

I see no good reason to have so many different adhoc instrumentation
mechanisms for profiling (sched, vm, oprofile) and tracing (blktrace,
suspend/resume tracing) all over the place. Merging them in a single
directory seems like a good step towards a more generic
instrumentation/profiling/tracing infrastructure.


Moving files about in directories should be at the /lowest/ end of the 
priority scale.  It makes diffs unreadable, file histories and diffing 
difficult, and a host of other problems.


Please solve the /real/ problems, and then come back and clean up the 
file structure after that is done.  Massive file renaming to satisfying 
some imagined future everything-is-golden scheme is the /last/ step.  It 
is the last step taken because the previous steps inevitably give you 
guidance that you otherwise would not have had at the start of the task.


When I try to diff between old and new alpha oprofile code, I really 
want to know that the reason why diffing is a pain in the ass is more 
than "it seemed like a good first step."




Back to "profile" and "probes" directory names, they might be short, but
they do not represent the whole markup-profiling-tracing trio,
"profile" lacks the tracing part and "probe" lacks the markup part.


You can always add more letters (and words) to even reach the desired 
level of specificity.  That does nothing to help readability though.


Anyway, it should be clear from existing precedent -- existing pathnames 
-- that "instrumentation" is too long, and really IMO too vague anyway.


Jeff


-
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: Out-of-tree modules [was: Linux Security *Module* Framework]

[Lee Revell]

On 10/29/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> quad_dsp - http://jengelh.hopto.org/p/quad_dsp/
>
> Provides a /dev/dsp style node for legacy applications that support
> neither ALSA nor the AOSS wrapper nor more-than-2-channel sound.
>

(I think that should read "AND more than 2 channel sound")

Couldn't ALSA's OSS emulation be extended to support more than 2
channels per device node?

>
> thkd - 
> ftp://ftp5.gwdg.de/pub/linux/misc/suser-jengelh/kernel/linux-2.6.23.1-ccj58/thkd.diff
>
> Workaround for Toshiba MK2003GAH hard-drive head auto-unloading after
> 5-15 seconds. (Ref: http://lkml.org/lkml/2006/11/15/100 )

It looks like this could be trivially fixed in a mergeable way.  That
LKML thread petered out before the problem was seriously analyzed.

Did you try the -Z flag of hdparm?

Lee
-
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: 32bit builds on x86-64 host.

[Dave Jones]

On Mon, Oct 29, 2007 at 05:07:08PM -0700, H. Peter Anvin wrote:
 > Dave Jones wrote:
 > > Before the arch merge, I frequently would test 32bit compiles
 > > by doing make ARCH=i386 {bzImage/modules/file.o}
 > > 
 > > Since commit 47572387d58a9584c60ebbbdee56fc92c627f16f
 > > how does one do this?
 > > 
 > 
 > make ARCH=i386 {bzImage/modules/file.o}
 > 
 > Amazing, isn't it?

It's like the future.   I'm not sure why that didn't work for me.
Must be something in my dirty tree.

Dave
-- 
http://www.codemonkey.org.uk
-
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: eradicating out of tree modules

[Tilman Schmidt]

Am 28.10.2007 20:25 schrieb Adrian Bunk:
> On Sun, Oct 28, 2007 at 07:51:12PM +0100, Tilman Schmidt wrote:
>> Am 28.10.2007 02:55 schrieb Adrian Bunk:
>>> Justifying anything with code with not GPL compatible licences has zero 
>>> relevance here.
>>>
>>> And there's value in making life harder for such modules with 
>>> questionable legality. As an example, consider people who experienced 
>>> crashes of "the Linux kernel" caused by some binary-only driver.
>>> Not that uncommon e.g. with some graphics drivers.
>>> This harms the reputation of Linux as being stable.
>> You are mixing up several distinct categories here: "out of tree"
>> != "non-GPL" != "proprietary" != "of questionable legality" !=
>> "binary-only" != "causing kernel crashes".
> 
> "binary-only non-GPL out-of-tree module causes kernel crashes" is a 
> quite common pattern for some popular binary-only modules.

Common, yes. Popular, maybe. The only one, not. Taking that as reason
for breaking out-of-tree open source modules is throwing out the baby
with the bathwater.

>>> The solution is not to support proprietary drivers, the solution is to 
>>> get open source replacements.
>> So how do you propose to "get" those replacements? And what shall
>> users do during the time this "getting" may take?
> 
> They should swamp the hardware vendors with requests for releasing 
> hardware specifications.

They are doing that already. But somehow it fails to magically cause
open source drivers to spring into existence immediately. The crucial
word here is *time*.

> Or even better buy their hardware from a competitor.

Hmmm. "Your existing hardware isn't supported anymore, buy new one?"
I thought that was a Microsoft line. (SCNR)

>>> If it's low quality code doing something useful - well, how many hundred 
>>> people are on Greg's list only waiting for some driver they could write?
>> No idea. Obviously not enough to actually solve the problem.
> 
> Greg has just begins with getting this started.

Exactly. Again, the problem is time. Deliberately breaking external
modules now and promising an in-tree alternative for later leaves
users out in the cold. That won't do much to improve the reputation
of Linux.

>> What solution do you propose?
> 
> You list the drivers you currently have in mind at the Linux Driver 
> Project [1].

They are all there already.

> Noone proposed to make the existance of out-of-tree modules completely 
> impossible - but it is a fact that derives directly from the Linux 
> kernel development model that thre's no stable API for out-of-tree 
> modules, and therefore each new kernel breaks many of them.

Granted.

> Once you accept this fundamental fact there's not much point in arguing 
> that changes that break out-of-tree modules should be fewer.

Granted. But that's not the point I was arguing anyway.

There is still a point in arguing that breaking out-of-tree modules
is not a goal. It's acceptable collateral damage if there is a good
reason for a change, but it doesn't by and in itself constitute such
a reason. That's why I'm taking exception with your statement in
<[EMAIL PROTECTED]>:
> [...] even though it might sound harsh breaking 
> external modules and thereby making people aware that their code should 
> get into the kernel is IMHO a positive point.

Breaking external modules is *not* positive. It's acceptable, but
everything else being equal it's still better to avoid it.

>>> Let me repeat that Greg has said he has hundreds of volunteers for such 
>>> tasks.
>> Even with hundreds of volunteers, your proposed solution of just
>> rewriting *all* external code in a way fit for inclusion into the
>> kernel is an unachievable goal. Just look at the list on
>> http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
>> and try to answer why each of them is still out of tree.
>> Hint: In most cases it's neither out of malice nor stupidity on
>> the authors' part.
> 
> There are different problems why different drivers are not (yet) 
> included in the kernel, but which ones don't have any possible solution?

I'm convinced all of them have possible solutions. The challenge
is to turn a possible solution into an actual one. And again, the
problem is time.

> And if you compare the numbers you'll see that Greg has on average a 
> handful of volunteers for one driver.

Not every problem can be solved faster by throwing more people at
it. Take mISDN as an example. Its developers have stated the goal
of inclusion in the main kernel tree years ago and it's still not
there. Deliberately breaking this external module "to make people
aware that their code should get into the kernel" would only delay
this goal even more. But sending them a handful of new volunteers
now would probably constitute the proverbial "adding manpower to a
late project".

> The most important question is still:
> 
> Why should there always be out-of-tree code that fills a real need not 
> satisfied by any in-tree code?

Because every in-tree 

Re: Abit F-190HD Onboard rlt8169 Ethernet Controller

[Ciaran McCreesh]

On Mon, 29 Oct 2007 13:00:07 +0100
Francois Romieu <[EMAIL PROTECTED]> wrote:
> Jeff Garzik <[EMAIL PROTECTED]> :
> [...]
> > Regardless, I agree with your "you...have a return candidate"
> > comment.
> 
> I would welcome a complete lspci -vxx + dmesg before the board is
> eventually returned though.

Attached.

Cheers,
-- 
Ciaran McCreesh[0.00] Linux version 2.6.24-rc1 ([EMAIL PROTECTED]) (gcc version 4.1.2 
(Gentoo 4.1.2 p1.0.2)) #4 SMP Mon Oct 29 05:54:50 GMT 2007
[0.00] Command line: root=/dev/sda1
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 0009f400 (usable)
[0.00]  BIOS-e820: 0009f400 - 000a (reserved)
[0.00]  BIOS-e820: 000f - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - cfff (usable)
[0.00]  BIOS-e820: cfff - cfff3000 (ACPI NVS)
[0.00]  BIOS-e820: cfff3000 - d000 (ACPI data)
[0.00]  BIOS-e820: e000 - f000 (reserved)
[0.00]  BIOS-e820: fec0 - 0001 (reserved)
[0.00]  BIOS-e820: 0001 - 00012000 (usable)
[0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used
[0.00] Entering add_active_range(0, 256, 851952) 1 entries of 256 used
[0.00] Entering add_active_range(0, 1048576, 1179648) 2 entries of 256 
used
[0.00] end_pfn_map = 1179648
[0.00] DMI 2.5 present.
[0.00] ACPI: RSDP 000F7C70, 0014 (r0 RS600 )
[0.00] ACPI: RSDT CFFF3000, 0038 (r1 RS600  AWRDACPI 42302E31 AWRD  
  0)
[0.00] ACPI: FACP CFFF3080, 0074 (r1 RS600  AWRDACPI 42302E31 AWRD  
  0)
[0.00] ACPI: DSDT CFFF3100, 5144 (r1 RS600  AWRDACPI 1000 MSFT  
300)
[0.00] ACPI: FACS CFFF, 0040
[0.00] ACPI: HPET CFFF8340, 0038 (r1 RS600  AWRDACPI 42302E31 AWRD  
 98)
[0.00] ACPI: MCFG CFFF8380, 003C (r1 RS600  AWRDACPI 42302E31 AWRD  
  0)
[0.00] ACPI: APIC CFFF8280, 0084 (r1 RS600  AWRDACPI 42302E31 AWRD  
  0)
[0.00] ACPI: SSDT CFFF8CE0, 0380 (r1  PmRefCpuPm 3000 INTL 
20040311)
[0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used
[0.00] Entering add_active_range(0, 256, 851952) 1 entries of 256 used
[0.00] Entering add_active_range(0, 1048576, 1179648) 2 entries of 256 
used
[0.00] Zone PFN ranges:
[0.00]   DMA 0 -> 4096
[0.00]   DMA324096 ->  1048576
[0.00]   Normal1048576 ->  1179648
[0.00] Movable zone start PFN for each node
[0.00] early_node_map[3] active PFN ranges
[0.00] 0:0 ->  159
[0.00] 0:  256 ->   851952
[0.00] 0:  1048576 ->  1179648
[0.00] On node 0 totalpages: 982927
[0.00]   DMA zone: 56 pages used for memmap
[0.00]   DMA zone: 1451 pages reserved
[0.00]   DMA zone: 2492 pages, LIFO batch:0
[0.00]   DMA32 zone: 14280 pages used for memmap
[0.00]   DMA32 zone: 833576 pages, LIFO batch:31
[0.00]   Normal zone: 1792 pages used for memmap
[0.00]   Normal zone: 129280 pages, LIFO batch:31
[0.00]   Movable zone: 0 pages used for memmap
[0.00] ATI board detected. Disabling timer routing over 8254.
[0.00] ACPI: PM-Timer IO Port: 0x4008
[0.00] ACPI: Local APIC address 0xfee0
[0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[0.00] Processor #0 (Bootup-CPU)
[0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
[0.00] Processor #1
[0.00] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x03] enabled)
[0.00] Processor #3
[0.00] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
[0.00] Processor #2
[0.00] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[0.00] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[0.00] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
[0.00] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
[0.00] ACPI: IOAPIC (id[0x04] address[0xfec0] gsi_base[0])
[0.00] IOAPIC[0]: apic_id 4, address 0xfec0, GSI 0-23
[0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
[0.00] ACPI: IRQ0 used by override.
[0.00] ACPI: IRQ2 used by override.
[0.00] ACPI: IRQ9 used by override.
[0.00] Setting APIC routing to flat
[0.00] ACPI: HPET id: 0x10b9a201 base: 0xfed0
[0.00] Using ACPI (MADT) for SMP configuration information
[0.00] Allocating PCI resources starting at d100 (gap: 
d000:1000)
[0.00] SMP: Allowing 4 CPUs, 0 hotplug CPUs
[0.00] PERCPU: Allocating 29360 bytes of per cpu data
[0.00] Built 1 zonelists 

Re: [PATCH] raise tsc clocksource rating

[H. Peter Anvin]

Glauber de Oliveira Costa wrote:

From: Glauber de Oliveira Costa <[EMAIL PROTECTED]>

tsc is very good time source (when it does not have drifts, does not
change it's frequency, i.e. when it works), so it should have its rating
raised to a value greater than, or equal 400.

Since it's being a tendency among paravirt clocksources to use values
around 400, we should declare tsc as even better: So we use 500.

This patch also touches the comments on clocksource.h, which suggests
that 499 would be a limit on the rating values.

Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>


Are you sure these paravirt sources don't intentionally trump the TSC?

-hpa

-
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] remove support for un-needed _extratext section

[Robin Getz]

On Mon 29 Oct 2007 18:22, Andrew Morton pondered:

> I hit numerous rejects here.  I am not sure which kernel you patched but
> I suspect it was not an up-to-date one.

Sorry about that - I will do so in the future. Thanks for reviewing and fixing 
up.

> > --- kernel/kallsyms.c   (revision 3780)
> > +++ kernel/kallsyms.c   (working copy)
> 
> Please prepare patches in `patch -p1' form.  This should have been
> 
> --- foo/kernel/kallsyms.c (revision 3780)
> +++ bar/kernel/kallsyms.c (working copy)

Sorry twice.

> >  */
> > if ((s->addr == _etext && strcmp((char*)s->sym + offset, 
> > "_etext")) ||
> > -   (s->addr == _einittext && strcmp((char*)s->sym + offset, 
> > "_einittext")) ||
> > -   (s->addr == _eextratext && strcmp((char*)s->sym + offset, 
> > "_eextratext")))
> > +   (s->addr == _einittext && strcmp((char*)s->sym + offset, 
> > "_einittext")))
> > return 0;
> > }
> 
> I don't understand why this hunk is changing _einittext handling, and I
> suspect this was a mistake, so I left that bit out.

I didn't think I did change the _einittext handling - just removed
_eextratext, and removed the trailing ||, and closed the parentheses for 
the if statement.

-  (s->addr == _einittext && strcmp((char*)s->sym + offset, "_einittext")) ||
+  (s->addr == _einittext && strcmp((char*)s->sym + offset, "_einittext")))

I think this is the same as what you have here - isn't it?

> - if ((s->addr == _etext && strcmp((char*)s->sym + offset, 
> "_etext")) ||
> - (s->addr == _einittext && strcmp((char*)s->sym + offset, 
> "_einittext")) ||
> - (s->addr == _eextratext && strcmp((char*)s->sym + offset, 
> "_eextratext")))
> + if ((s->addr == _etext &&
> + strcmp((char*)s->sym + offset, "_etext")) ||
> + (s->addr == _einittext &&
> + strcmp((char*)s->sym + offset, "_einittext")))
>   return 0;

?
-
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/2] [CRYPTO] tcrypt: Move sg_init_table out of timing loops

[Herbert Xu]

On Mon, Oct 29, 2007 at 09:16:27PM +0100, Jens Axboe wrote:
> On Fri, Oct 26 2007, Herbert Xu wrote:
> > [CRYPTO] tcrypt: Move sg_init_table out of timing loops
> > 
> > This patch moves the sg_init_table out of the timing loops for hash
> > algorithms so that it doesn't impact on the speed test results.
> 
> Wouldn't it be better to just make sg_init_one() call sg_init_table?

This looks fine to me although I think it's orthogonal to the
patch you were quoting :)

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: 32bit builds on x86-64 host.

[H. Peter Anvin]

Dave Jones wrote:

Before the arch merge, I frequently would test 32bit compiles
by doing make ARCH=i386 {bzImage/modules/file.o}

Since commit 47572387d58a9584c60ebbbdee56fc92c627f16f
how does one do this?



make ARCH=i386 {bzImage/modules/file.o}

Amazing, isn't it?

-hpa
-
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] Revert x86: add lapic_shutdown for x86_64

[Hiroshi Shimamoto]

Arjan van de Ven wrote:
> On Mon, 29 Oct 2007 15:39:46 -0700
> Hiroshi Shimamoto <[EMAIL PROTECTED]> wrote:
> 
>> lapic_shutdown is useless on x86_64.
>>
> 
>  but since the goal is to get apic_32.c and apic_64.c to be more
> converging (to the point of becoming the same file)... isn't your patch
> going in the opposite direction?
> 
Hmm, I'm not sure that this revert affects x86 unification.
Vivek said that probably we don't have to introduce lapic_shutdown() for 64bit.
So I submitted this patch which reverts my previous post, it was applied before
the comment.

Thanks
Hiroshi Shimamoto
-
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: 32bit builds on x86-64 host.

[Al Viro]

On Mon, Oct 29, 2007 at 07:32:31PM -0400, Dave Jones wrote:
> Before the arch merge, I frequently would test 32bit compiles
> by doing make ARCH=i386 {bzImage/modules/file.o}
> 
> Since commit 47572387d58a9584c60ebbbdee56fc92c627f16f
> how does one do this?

Same.  Top-level makefile kludges around that:

SRCARCH := $(ARCH)

# for i386 and x86_64 we use SRCARCH equal to x86
SRCARCH := $(if $(filter x86_64 i386,$(SRCARCH)),x86,$(SRCARCH))

and then plays with both ARCH and SRCARCH.  Note
# If a arch/$(SRCARCH)/Kconfig.$(ARCH) file exist use it
ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/Kconfig.$(ARCH)),)
Kconfig := arch/$(SRCARCH)/Kconfig.$(ARCH)
else
Kconfig := arch/$(SRCARCH)/Kconfig
endif

in scripts/kconfig/Makefile, BTW - now we use arch/x86/Kconfig.i386 and
arch/x86/Kconfig.x86_64 as starting points for ARCH=i386 and ARCH=x86_64
resp.
-
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: Page-Out of RO data

[Robert Hancock]

vicky wrote:

Hi,
Can Read-Only(RO) Section/Data of kernel can ever be paged out memory?

-Vicky



All kernel code and data is non-swappable in Linux..

--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

-
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] [LXFB] Use the correct MSR number for panel support

[H. Peter Anvin]

Jordan Crouse wrote:

From: Jordan Crouse <[EMAIL PROTECTED]>

A relatively recent version of the Geode LX datasheet listed the wrong
address for one of the MSRs that controls TFT panels, resulting in 
breakage.  This patch corrects the MSR address.


Signed-off-by: Jordan Crouse <[EMAIL PROTECTED]>
---

 drivers/video/geode/lxfb.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/video/geode/lxfb.h b/drivers/video/geode/lxfb.h
index 6c227f9..ca13c48 100644
--- a/drivers/video/geode/lxfb.h
+++ b/drivers/video/geode/lxfb.h
@@ -33,7 +33,7 @@ void lx_set_palette_reg(struct fb_info *, unsigned int, 
unsigned int,
 
 #define MSR_LX_GLD_CONFIG0x48002001

 #define MSR_LX_GLCP_DOTPLL   0x4c15
-#define MSR_LX_DF_PADSEL 0x4811
+#define MSR_LX_DF_PADSEL 0x48002011
 #define MSR_LX_DC_SPARE  0x8011
 #define MSR_LX_DF_GLCONFIG   0x48002001
 


Please put MSR indicies in  and/or a separate 
include file.


-hpa
-
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: Strange freezes (seems like SATA related)

[Robert Hancock]

Max Krasnyansky wrote:

A couple of HP xw9300 machines (dual Opterons) started freezing up.
We're running on 2.6.22.1 on them. Freezes a somewhere weird. VGA console is 
alive
(I can switch vts, etc) but everything else is dead (network, etc).
Unfortunately SYSRQ was not enabled and I could not get backtraces and stuff.

Hooked up serial console and the only error that shows up is this.

ata1: EH in ADMA mode, notifier 0x1 notifier_error 0x0 gen_ctl 0x1581000 status 
0x1540 next cpb count 0x0 next cpb idx 0x0
ata1: CPB 0: ctl_flags 0xd, resp_flags 0x1
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: cmd ca/00:08:57:00:80/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 out
 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Descriptor sense data with sense descriptors (in hex):
end_request: I/O error, dev sda, sector 8388695
Buffer I/O error on device sda1, logical block 1048579
lost page write due to I/O error on sda1
sd 0:0:0:0: [sda] Write Protect is off

I see a bunch of those and then the box just sits there spewing this 
periodically

ata1: EH in ADMA mode, notifier 0x1 notifier_error 0x0 gen_ctl 0x1581000 status 
0x1540 next cpb count 0x0 next cpb idx 0x0
ata1: CPB 0: ctl_flags 0xd, resp_flags 0x1
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: cmd ca/00:08:4f:00:f8/00:00:00:00:00/e1 tag 0 cdb 0x0 data 4096 out
 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

SMART selftest on the drive passed without errors.

Here is how this machine looks like

00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio 
Controller (rev a2)
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2)
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address 
Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM 
Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
Miscellaneous Control
00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
HyperTransport Technology Configuration
00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address 
Map
00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM 
Controller
00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
Miscellaneous Control
05:04.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 
7000/VE]
05:05.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 
Controller (PHY/Link)
0a:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet 
Controller (Copper) (rev 06)
40:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12)
40:01.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01)
40:02.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12)
40:02.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01)
61:04.0 PCI bridge: Intel Corporation Unknown device 537c (rev 07)
61:06.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X 
Fusion-MPT Dual Ultra320 SCSI (rev 07)
61:06.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X 
Fusion-MPT Dual Ultra320 SCSI (rev 07)
61:09.0 PCI bridge: Intel Corporation Unknown device 537c (rev 07)
62:09.0 Multimedia controller: BittWare, Inc. Unknown device 0035 (rev 01)
63:09.0 Multimedia controller: BittWare, Inc. Unknown device 0035 (rev 01)
80:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
80:01.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
80:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
81:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet 
Controller (Copper) (rev 06)

As I mentioned dual Opteron, NUMA. Nothing fancy in the kernel config. 


Any ideas what might the problem be ?


Can you post the full dmesg output? What kind of drive is this?

--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line "unsubscribe 

Re: [PATCH resend] Make the dev_*() family of macros in device.h complete

[Greg KH]

On Mon, Oct 29, 2007 at 05:43:15PM -0500, Emil Medve wrote:
> Removed duplicates defined elsewhere
> 
> Signed-off-by: Emil Medve <[EMAIL PROTECTED]>
> ---
> 
> Reseding the patch to a larger audience
> 
> The macros are defined in the relative order KERN_* are defined in kernel.h
> 
> linux-2.6> scripts/checkpatch.pl 
> 0001-Make-the-dev_-family-of-macros-in-device.h-comple.patch 
> Your patch has no obvious style problems and is ready for submission.
> 
>  drivers/i2c/chips/isp1301_omap.c |6 --
>  drivers/isdn/gigaset/gigaset.h   |6 --
>  include/linux/device.h   |   26 --
>  3 files changed, 16 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/i2c/chips/isp1301_omap.c 
> b/drivers/i2c/chips/isp1301_omap.c
> index fe04e46..35b9909 100644
> --- a/drivers/i2c/chips/isp1301_omap.c
> +++ b/drivers/i2c/chips/isp1301_omap.c
> @@ -259,12 +259,6 @@ static inline const char *state_name(struct isp1301 *isp)
>   return state_string(isp->otg.state);
>  }
>  
> -#ifdef   VERBOSE
> -#define  dev_vdbgdev_dbg
> -#else
> -#define  dev_vdbg(dev, fmt, arg...)  do{}while(0)
> -#endif
> -
>  /*-*/
>  
>  /* NOTE:  some of this ISP1301 setup is specific to H2 boards;
> diff --git a/drivers/isdn/gigaset/gigaset.h b/drivers/isdn/gigaset/gigaset.h
> index a0317ab..02bdaf2 100644
> --- a/drivers/isdn/gigaset/gigaset.h
> +++ b/drivers/isdn/gigaset/gigaset.h
> @@ -106,12 +106,6 @@ enum debuglevel {
>activated */
>  };
>  
> -/* missing from linux/device.h ... */
> -#ifndef dev_notice
> -#define dev_notice(dev, format, arg...)  \
> - dev_printk(KERN_NOTICE , dev , format , ## arg)
> -#endif
> -
>  /* Kernel message macros for situations where dev_printk and friends cannot 
> be
>   * used for lack of reliable access to a device structure.
>   * linux/usb.h already contains these but in an obsolete form which clutters
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 2e15822..e4f8a1c 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -557,9 +557,24 @@ extern const char *dev_driver_string(struct device *dev);
>  #define dev_printk(level, dev, format, arg...)   \
>   printk(level "%s %s: " format , dev_driver_string(dev) , (dev)->bus_id 
> , ## arg)
>  
> +#define dev_emerg(dev, format, arg...)   \
> + dev_printk(KERN_EMERG, dev, format, ## arg)
> +#define dev_alert(dev, format, arg...)   \
> + dev_printk(KERN_ALERT, dev, format, ## arg)
> +#define dev_crit(dev, format, arg...)\
> + dev_printk(KERN_CRIT, dev, format, ## arg)
> +#define dev_err(dev, format, arg...) \
> + dev_printk(KERN_ERR, dev, format, ## arg)
> +#define dev_warn(dev, format, arg...)\
> + dev_printk(KERN_WARNING, dev, format, ## arg)
> +#define dev_notice(dev, format, arg...)  \
> + dev_printk(KERN_NOTICE, dev, format, ## arg)
> +#define dev_info(dev, format, arg...)\
> + dev_printk(KERN_INFO, dev, format, ## arg)
> +
>  #ifdef DEBUG
>  #define dev_dbg(dev, format, arg...) \
> - dev_printk(KERN_DEBUG , dev , format , ## arg)
> + dev_printk(KERN_DEBUG, dev, format, ## arg)

Those extra spaces are there for a good reason, older versions of gcc
are broken without it.  So please, put them all back...

thanks,

greg k-h
-
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/

Out-of-tree modules [was: Linux Security *Module* Framework]

[Jan Engelhardt]

On Oct 25 2007 19:56, Greg KH wrote:

>What kind of code is not accepted into the mainline kernel tree for good
>reasons?  What are these reasons?  What specific code are you talking
>about?
>
>I'm trying to compile a list of all known external modules and drivers
>and work to get them included in the main kernel tree to help prevent
>these kinds of things.  If you know of any that are not on the list at:
>   http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
>please feel free to add them, or email me with the needed information
>and I will add them to the list.


quad_dsp - http://jengelh.hopto.org/p/quad_dsp/

Provides a /dev/dsp style node for legacy applications that support 
neither ALSA nor the AOSS wrapper nor more-than-2-channel sound.


thkd - 
ftp://ftp5.gwdg.de/pub/linux/misc/suser-jengelh/kernel/linux-2.6.23.1-ccj58/thkd.diff

Workaround for Toshiba MK2003GAH hard-drive head auto-unloading after 
5-15 seconds. (Ref: http://lkml.org/lkml/2006/11/15/100 )
-
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: pci-disable-decode-of-io-memory-during-bar-sizing.patch

[Robert Hancock]

Greg KH wrote:

On Fri, Oct 26, 2007 at 09:59:45AM -0700, Jesse Barnes wrote:

On Thursday, October 25, 2007 7:54 pm Greg KH wrote:

On Thu, Oct 25, 2007 at 04:22:35PM -0700, Jesse Barnes wrote:

I think Greg doesn't like it, even though we don't have an
alternative at this point...

Yes, I didn't like it, Ivan didn't like it, and I got reports that it
wasn't even needed at all once you upgraded your BIOS to the latest
version.

So, is this still needed?  And if so, can you try to implement what
Ivan suggested to do here instead?
Yes, it's still needed.  Auke rescinded his "BIOS upgrade makes it work" 
message, so something like this is still necessary.


He did?  Ugh, I can't keep these all straight, sorry.

Can someone just send what they think is still needed, and explain why
Ivan will not object to it?  :)


Here's a recap of the whole issue just for people's information:

Right now we disable MMCONFIG on machines where the MCFG area is not 
reserved in the E820 memory map since we figure it's not valid. This is 
a broken heuristic because the PCI Express firmware spec doesn't require 
that it be so reserved, it only needs to be reserved as an ACPI 
motherboard resource, and so many times it's not reserved in E820 
despite being completely valid and working. The 
mmconfig-validate-against-acpi-motherboard-resources.patch changes this 
to validate against the ACPI motherboard resources instead.


The second problem is that on some machines, when we are doing BAR 
sizing on PCI devices, and write all ones to a BAR in order to determine 
how many bits "stick", the BAR ends up overlapping with the MCFG area. 
On some chipsets, this causes writes to the MCFG area (like, to restore 
the original BAR contents) to get decoded by the device instead of by 
the MCFG mechanism, which means the BAR stays disabled and configuration 
access stops working, wreaking havoc. Usually on these machines the 
MMCONFIG is located near the top of 32-bit memory and the PCI device 
causing problems is a PCI Express graphics card. 
pci-disable-decode-of-io-memory-during-bar-sizing.patch, and its 
successors, switch off the device's decoding during sizing so that it 
won't absorb the accesses to the MCFG table.


The concern raised was that this might affect some devices negatively. 
We do avoid disabling decode on host bridges, as it's known that some of 
them disable RAM access when you turn decode off, stupidly. I've yet to 
hear of any other conclusive case where disabling the decode is harmful. 
In general, if disabling the decode causes issues, the mere fact of 
doing the BAR sizing could cause the same issues, and that is unavoidable.


The other possible workaround would be to avoid using MMCONFIG until the 
BAR sizing is done. However, this seems like a poor solution. First of 
all, in the future there may come machines where MMCONFIG is the only 
config mechanism (or, perhaps more likely, it becomes the only tested 
one, so the old methods get broken). Secondly, what happens with 
hot-plug devices that need to be sized after MMCONFIG gets turned on?


The only way these two patches are related is that the E820 check 
happens to wrongly disable MMCONFIG on some of the machines where the 
memory areas could overlap during sizing, so removing that check alone 
without fixing the overlap issue could cause breakage on some machines. 
However, this is purely by chance, and it doesn't prevent the breakage 
on many other machines - as well as the one mentioned in the earlier 
thread, there's this one:


https://bugzilla.redhat.com/show_bug.cgi?id=251493

--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
-
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/

[Git pull] x86 update

[Thomas Gleixner]

Linus,

please pull from:

  ssh://master.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git

a couple of cleanups and bugfixes along with a compile/runtime
irrelevant doc change.

The iommu.h -> gart.h rename needs to go in before we have the
namespace polution all over the place.

Thanks,

tglx

Adrian Bunk (4):
  x86: kernel/setup_32.c: unexport machine_id
  x86: mm/discontig_32.c: make code static
  x86: merge EARLY_PRINTK options
  remove the dead X86_REMOTE_DEBUG option

H. Peter Anvin (1):
  x86: additional CPUID strings; fix strings for AMD-ecx

Huang, Ying (1):
  x86 boot: document for 32 bit boot protocol

Joerg Roedel (4):
  x86 gart: rename iommu.h to gart.h
  x86 gart: rename CONFIG_IOMMU to CONFIG_GART_IOMMU
  x86 gart: make some variables and functions static
  x86 gart: rename symbols only used for the GART implementation

 Documentation/i386/boot.txt   |   38 
 Documentation/i386/zero-page.txt  |  122 
 arch/x86/Kconfig.debug|8 +--
 arch/x86/Kconfig.x86_64   |   10 +--
 arch/x86/configs/x86_64_defconfig |2 +-
 arch/x86/kernel/Makefile_64   |2 +-
 arch/x86/kernel/aperture_64.c |   15 +++--
 arch/x86/kernel/cpu/proc.c|   10 ++--
 arch/x86/kernel/early-quirks.c|   10 ++--
 arch/x86/kernel/pci-calgary_64.c  |2 +-
 arch/x86/kernel/pci-dma_64.c  |   10 ++--
 arch/x86/kernel/pci-gart_64.c |   18 +++---
 arch/x86/kernel/pci-nommu_64.c|2 +-
 arch/x86/kernel/pci-swiotlb_64.c  |2 +-
 arch/x86/kernel/reboot_64.c   |2 +-
 arch/x86/kernel/setup_32.c|3 -
 arch/x86/kernel/setup_64.c|   10 ++--
 arch/x86/mm/discontig_32.c|4 +-
 drivers/char/agp/Kconfig  |4 +-
 drivers/char/agp/amd64-agp.c  |2 +-
 drivers/pci/intel-iommu.c |2 +-
 drivers/usb/core/message.c|2 +-
 include/asm-x86/gart.h|   29 +
 include/asm-x86/iommu.h   |4 +-
 include/asm-x86/pci_64.h  |2 +-
 25 files changed, 152 insertions(+), 163 deletions(-)
 create mode 100644 include/asm-x86/gart.h
diff --git a/Documentation/i386/boot.txt b/Documentation/i386/boot.txt
index 2f75e75..fc49b79 100644
--- a/Documentation/i386/boot.txt
+++ b/Documentation/i386/boot.txt
@@ -785,3 +785,41 @@ IMPORTANT: All the hooks are required to preserve %esp, 
%ebp, %esi and
After completing your hook, you should jump to the address
that was in this field before your boot loader overwrote it
(relocated, if appropriate.)
+
+
+ 32-bit BOOT PROTOCOL
+
+For machine with some new BIOS other than legacy BIOS, such as EFI,
+LinuxBIOS, etc, and kexec, the 16-bit real mode setup code in kernel
+based on legacy BIOS can not be used, so a 32-bit boot protocol needs
+to be defined.
+
+In 32-bit boot protocol, the first step in loading a Linux kernel
+should be to setup the boot parameters (struct boot_params,
+traditionally known as "zero page"). The memory for struct boot_params
+should be allocated and initialized to all zero. Then the setup header
+from offset 0x01f1 of kernel image on should be loaded into struct
+boot_params and examined. The end of setup header can be calculated as
+follow:
+
+   0x0202 + byte value at offset 0x0201
+
+In addition to read/modify/write the setup header of the struct
+boot_params as that of 16-bit boot protocol, the boot loader should
+also fill the additional fields of the struct boot_params as that
+described in zero-page.txt.
+
+After setupping the struct boot_params, the boot loader can load the
+32/64-bit kernel in the same way as that of 16-bit boot protocol.
+
+In 32-bit boot protocol, the kernel is started by jumping to the
+32-bit kernel entry point, which is the start address of loaded
+32/64-bit kernel.
+
+At entry, the CPU must be in 32-bit protected mode with paging
+disabled; a GDT must be loaded with the descriptors for selectors
+__BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat
+segment; __BOOS_CS must have execute/read permission, and __BOOT_DS
+must have read/write permission; CS must be __BOOT_CS and DS, ES, SS
+must be __BOOT_DS; interrupt must be disabled; %esi must hold the base
+address of the struct boot_params; %ebp, %edi and %ebx must be zero.
diff --git a/Documentation/i386/zero-page.txt b/Documentation/i386/zero-page.txt
index 6c0817c..169ad42 100644
--- a/Documentation/i386/zero-page.txt
+++ b/Documentation/i386/zero-page.txt
@@ -1,99 +1,31 @@

-!!!WARNING
-The zero page is a kernel internal data structure, not a stable ABI.  It might 
change
-without warning and the kernel has no way to detect old version of it.
-If you're writing some external code like a boot loader you should only use
-the stable versioned real mode boot protocol described in boot.txt. Otherwise 

Re: [RFC] Create instrumentation directory (git repository)

[Christoph Lameter]

On Mon, 29 Oct 2007, Mathieu Desnoyers wrote:

> * Christoph Lameter ([EMAIL PROTECTED]) wrote:
> > On Mon, 29 Oct 2007, Mathieu Desnoyers wrote:
> > 
> > > vm/vmstat.c
> > 
> > The vm statistics are important for the operation of the VM. They are not 
> > optional. So I do not think that they fall under the category of 
> > instrumentation.
> 
> But I guess vm stats can be useful to others; a kernel tracer for
> instance ?

Yes.

> Putting stuff in instrumentation/ by no way means that it becomes
> optional for a subsystem, but merely that it could either export
> information useful for kernel instrumentation or have some
> infrastructure parts merged with others. 

The vm statistics are intricately connected with other mm code. Best leave 
it where it is. The other instrumentation is something that is put in 
particularly for gaining statistics.



-
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: [RFC] Create instrumentation directory (git repository)

[Mathieu Desnoyers]

* Jeff Garzik ([EMAIL PROTECTED]) wrote:
> Mathieu Desnoyers wrote:
> >* Jeff Garzik ([EMAIL PROTECTED]) wrote:
> >>Randy Dunlap wrote:
> >>>On Mon, 29 Oct 2007 17:51:38 -0400 Mathieu Desnoyers wrote:
> >>>
> Hi,
> 
> Since we already have the Instrumentation menu in
> kernel/Kconfig.instrumentation and instrumentation code all over the
> kernel tree:
> 
> arch/*/oprofile/*.c
> kernel/kprobes.c
> arch/*/kernel/kprobes.c
> kernel/marker.c
> kernel/profile.c
> kernel/lockdep.c
> vm/vmstat.c
> block/blktrace.c
> drivers/base/power/trace.c
> 
> We could move them to
> 
> instrumentation/
> arch/*/instrumentation/
> 
> Therefore, we could also move the kprobes and marker samples under
> 
> instrumentation/samples/
> 
> Here is a link to a git repository containing the changes, based on
> 2.6.24-rc1:
> 
> git://ltt.polymtl.ca/linux-2.6-instrumentation.git 
> instrumentation-for-linus
> (the interesting range is : v2.6.24-rc1..instrumentation-for-linus)
> 
> Through the gitweb interface:
> http://ltt.polymtl.ca/cgi-bin/gitweb.cgi?p=linux-2.6-instrumentation.git
> 
> Feedback is appreciated. Sorry for the huge CC list, but the change
> involves many maintainers.
> >>>Two more added.  Jeff Garzik and Christoph H. sometimes have some 
> >>>comments
> >>>about this.
> >>>
> >>>It would be helpful if we could get comments on this in the next day
> >>>or two [instead of in 1-2 weeks].
> >>"instrumentation" is long, and painful to the fingers :)
> >>
> >
> >Quoting my post from last week:
> >
> >>My main concern is that 15 characters long directory name might be
> >>inelegant (however, it only beats Documentation by 2).
> >
> >And quoting the answer from [EMAIL PROTECTED] :
> >How so?  i n s esc.  4 keystrokes (and still 2 more than D ;)
> >
> >
> >
> >Better suggestions are wery welcome. However, in modern shells,
> >auto-completion is cheap nowadays.
> 
> That is no excuse for extreme verbosity.  It makes ls(1) displays ugly, 
> it makes diffstat ugly, it causes long pathnames to be truncated in 
> various display-oriented programs.
> 
> Pick a shorter word like probes or profile or what... or better yet... 
> just leave most things in their current directories.
> 
> Shuffling files around just to put them into directories with extra-long 
> names is highly undesirable.
> 
> 

I'll keep the probes and profile directory name ideas in mind, thanks.

This patchset does more than moving things around : its purpose is to
gather various kernel files that have similar purpose (instrumentation)
into a single directory so that it becomes easier to work on these
without duplicating the effort.

I see no good reason to have so many different adhoc instrumentation
mechanisms for profiling (sched, vm, oprofile) and tracing (blktrace,
suspend/resume tracing) all over the place. Merging them in a single
directory seems like a good step towards a more generic
instrumentation/profiling/tracing infrastructure.

Back to "profile" and "probes" directory names, they might be short, but
they do not represent the whole markup-profiling-tracing trio,
"profile" lacks the tracing part and "probe" lacks the markup part.

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
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: [RFC] Create instrumentation directory (git repository)

[Mathieu Desnoyers]

* Christoph Lameter ([EMAIL PROTECTED]) wrote:
> On Mon, 29 Oct 2007, Mathieu Desnoyers wrote:
> 
> > vm/vmstat.c
> 
> The vm statistics are important for the operation of the VM. They are not 
> optional. So I do not think that they fall under the category of 
> instrumentation.

But I guess vm stats can be useful to others; a kernel tracer for
instance ?

Putting stuff in instrumentation/ by no way means that it becomes
optional for a subsystem, but merely that it could either export
information useful for kernel instrumentation or have some
infrastructure parts merged with others. 

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
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] raise tsc clocksource rating

[Jeremy Fitzhardinge]

Ingo Molnar wrote:
> i dont remember us having discussed this before, ever. If there's any 
> "fight" about monotonicity and SMP then it would be a pretty onesided 
> affair, with you being beaten up seriously ;-)
>   

This is part of Xen's ABI, so it isn't easily changed.  You're right
that getting monotonicity is a pretty ugly affair of doing something
like "if (now < previous_return) return ++previous_return;", but its
better than using the tsc.

(Last time around, it was "Xen can't use the tsc because it can't ever
be used as a stable timebase" - though I don't think that was you
specifically.)

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

[git pull] scheduler fix

[Ingo Molnar]

Linus, this is a followup git pull request for a single fix:

   git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched.git

Frans Pop has tested a fix from Balbir Singh that (finally) resolves the 
procps CPU accounting bug. The fix you pulled earlier today was correct 
but it solved only half of the problem.

Ingo

-->
Balbir Singh (1):
  sched: fix /proc//stat stime/utime monotonicity, part 2

 fs/proc/array.c   |3 ++-
 include/linux/sched.h |2 +-
 kernel/fork.c |1 +
 3 files changed, 4 insertions(+), 2 deletions(-)
-
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/

32bit builds on x86-64 host.

[Dave Jones]

Before the arch merge, I frequently would test 32bit compiles
by doing make ARCH=i386 {bzImage/modules/file.o}

Since commit 47572387d58a9584c60ebbbdee56fc92c627f16f
how does one do this?

Dave

-- 
http://www.codemonkey.org.uk
-
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 02/10] SLUB: Noinline some functions to avoid them being folded into alloc/free

[Matt Mackall]

On Sat, Oct 27, 2007 at 08:31:58PM -0700, Christoph Lameter wrote:
> Some function tend to get folded into __slab_free and __slab_alloc
> although they are rarely called. They cause register pressure that
> leads to bad code generation.

Nice - an example of uninlining to directly improve performance!

-- 
Mathematics is the supreme nostalgia of our time.
-
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: [stable] 2.6.23 regression: top displaying 9999% CPU usage

[Balbir Singh]

Frans Pop wrote:
> On Monday 29 October 2007, Balbir Singh wrote:
>> We'll also need this additional patch (untested),
> 
> OK. Both patches together do the trick. Gave it a nice long test run and got 
> no more weirdness.
> Tested-by: Frans Pop <[EMAIL PROTECTED]>
> 

Thanks for testing it

Ingo, I think this fix needs to be picked as well.

>> but in the long run I think the approach needs to be
>>
>> 1. Update stime and utime at the time of context switching -- keep it
>>in sync with p->sum_exec_runtime
>> 2. Keep track of system/user context at system call entry points
> 
> Feel free to send me a patch for testing when you have one.
> 

I hope to find some free time soon and get to it.

> Cheers,
> Frans


-- 
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
-
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: [build bug, 2.6.24-rc1] CONFIG_VIDEO_DEV=m & CONFIG_VIDEO_SAA7146_VV=y

[Randy Dunlap]

On Mon, 29 Oct 2007 13:35:33 +0100 Johannes Stezenbach wrote:

> On Mon, Oct 29, 2007, Ingo Molnar wrote:
> > * Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > 
> > > > config VIDEO_SAA7146_VV
> > > > tristate
> > > > depends on VIDEO_DEV = y || VIDEO_DEV = VIDEO_SAA7146_VV
> > > > select VIDEOBUF_DMA_SG
> > > > select VIDEO_SAA7146
> > > > 
> > > > (untested)
> > > 
> > > Nope, won't work.  I tried that last night.  VIDEO_DEV_SAA7146_VV
> > > has too many "select"s involved, but select doesn't follow the dependency
> > > chains.  IOW, as written in Documentation/kbuild/kconfig-language.txt:
> > > 
> > >   select is evil select will by brute force set a symbol
> > >   equal to 'y' without visiting the dependencies. So abusing
> > >   select you are able to select a symbol FOO even if FOO depends
> > >   on BAR that is not set.
> > 
> > so ... what should we do? Remove those ~7 select VIDEO_SAA7146_VV lines 
> > and replace them with depends on VIDEO_SAA7146_VV ?
> 
> Hm, the idea is that the SAA7146 driver is like a library,
> and the V4L or DVB card drivers select the library functions
> they need (base driver or common V4L helper functions).
> The user shouldn't have to worry about those details.
> 
> But yeah, if it's not possible to do that with kbuild then
> it's probably best to s/select/depends on/ for VIDEO_SAA7146_VV
> and provide a meaningful help text for VIDEO_SAA7146_VV.

I don't have a better suggestion, but VIDEO_SAA7146_VV will need
a prompt and help text if a user can enable/disable it.

---
~Randy
-
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: [stable] 2.6.23 regression: top displaying 9999% CPU usage

[Ingo Molnar]

* Frans Pop <[EMAIL PROTECTED]> wrote:

> On Monday 29 October 2007, Balbir Singh wrote:
> > We'll also need this additional patch (untested),
> 
> OK. Both patches together do the trick. Gave it a nice long test run and got 
> no more weirdness.
> Tested-by: Frans Pop <[EMAIL PROTECTED]>

cool, thanks! I've queued it up for the next scheduler batch.

Ingo
-
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] raise tsc clocksource rating

[Ingo Molnar]

* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:

> Ingo Molnar wrote:
> > that's totally broken then. You cannot create an SMP-safe monotonic 
> > clocksource via interpolation - native does not do it either. Good thing 
> > this problem got exposed, it needs to be fixed.
> >   
> 
> Sigh, I don't really want to have this fight again.

i dont remember us having discussed this before, ever. If there's any 
"fight" about monotonicity and SMP then it would be a pretty onesided 
affair, with you being beaten up seriously ;-)

> I don't really see what point there is in raising the tsc's rating 
> (why is 300 insufficient again?), but regardless of the value, the Xen 
> clocksource rating needs to be higher.

anyway, i agree that this patch cannot go in in its current form.

Ingo
-
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] raise tsc clocksource rating

[Dan Hecht]

On 10/29/2007 04:02 PM, Ingo Molnar wrote:

* Zachary Amsden <[EMAIL PROTECTED]> wrote:


On Mon, 2007-10-29 at 23:48 +0100, Ingo Molnar wrote:

* Zachary Amsden <[EMAIL PROTECTED]> wrote:
if it's inaccurate why are you exposing it to the guest then? Native 
only uses the TSC if it's safe and accurate to do so.
Not every guest support paravirt, but for correctness, all guests 
require TSC, which must be exposed all the way up to userspace, no 
matter what the efficiency or accuracy may be.


but if there's a perfect TSC available (there is such hardware) then the 
TSC _is_ the best clocksource. Paravirt now turns it off unconditionally 
in essence.




Not really.  In the case hardware TSC is perfect, the paravirt time 
counter can be implemented directly in terms of hardware TSC; there is 
no loss in optimization.  This is done transparently.  And virtual TSC 
can be implemented this way too.


The real improvement that a paravirt clocksource offers over the TSC 
clocksource is that the guest does not need to measure the TSC frequency 
itself against some other constant frequency source (which is 
problematic on a virtual machine).  Instead, the paravirt clocksource 
queries the hypervisor for the frequency of the counter.  As you know, 
with clocksource style kernels, it's important to get this frequency 
correct, or else the guest will have long-term time drift.



-
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: [RFC] Create instrumentation directory (git repository)

[Christoph Lameter]

On Mon, 29 Oct 2007, Mathieu Desnoyers wrote:

> vm/vmstat.c

The vm statistics are important for the operation of the VM. They are not 
optional. So I do not think that they fall under the category of 
instrumentation.
-
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] Revert x86: add lapic_shutdown for x86_64

[Arjan van de Ven]

On Mon, 29 Oct 2007 15:39:46 -0700
Hiroshi Shimamoto <[EMAIL PROTECTED]> wrote:

> lapic_shutdown is useless on x86_64.
> 

 but since the goal is to get apic_32.c and apic_64.c to be more
converging (to the point of becoming the same file)... isn't your patch
going in the opposite direction?

-- 
If you want to reach me at my work email, use [EMAIL PROTECTED]
For development, discussion and tips for power savings, 
visit http://www.lesswatts.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/