[PATCH] fix modules oopsing in lguest guests

[Rusty Russell]

The assembly templates for lguest guest patching are in the .init.text
section.  This means that modules get patched with "cc cc cc cc" or
similar junk.

Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>

diff -r 554f72e059aa drivers/lguest/lguest_asm.S
--- a/drivers/lguest/lguest_asm.S   Thu Sep 13 16:56:44 2007 +1000
+++ b/drivers/lguest/lguest_asm.S   Mon Sep 24 15:34:31 2007 +1000
@@ -22,8 +22,9 @@
jmp lguest_init
 
 /*G:055 We create a macro which puts the assembler code between lgstart_ and
- * lgend_ markers.  These templates end up in the .init.text section, so they
- * are discarded after boot. */
+ * lgend_ markers.  These templates are put in the .text section: they can't be
+ * discarded after boot as we may need to patch modules, too. */
+.text
 #define LGUEST_PATCH(name, insns...)   \
lgstart_##name: insns; lgend_##name:;   \
.globl lgstart_##name; .globl lgend_##name
@@ -34,7 +35,6 @@ LGUEST_PATCH(pushf, movl lguest_data+LGU
 LGUEST_PATCH(pushf, movl lguest_data+LGUEST_DATA_irq_enabled, %eax)
 /*:*/
 
-.text
 /* These demark the EIP range where host should never deliver interrupts. */
 .global lguest_noirq_start
 .global lguest_noirq_end


-
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] Uninline kcalloc()

[Valdis . Kletnieks]

On Sun, 23 Sep 2007 00:03:49 +0400, Alexey Dobriyan said:

> -static inline void *kcalloc(size_t n, size_t size, gfp_t flags)
> -{
> - if (n != 0 && size > ULONG_MAX / n)
> - return NULL;
> - return __kmalloc(n * size, flags | __GFP_ZERO);
> -}
> +void *kcalloc(size_t n, size_t size, gfp_t flags);

NAK.

This busticates some pretty subtle code in mm/slab.c that uses
uses __builtin_return_address() for debugging - if you do this, then
the "calling function" gets listed as "kcalloc()" rather than the much more
useful "function that called kcalloc()" (which is what you care about).

(I remember going around and around multiple times getting those stupid
inlines set up right, so that feature actually did something useful, otherwise
kcalloc and kzalloc didn't report where they were called from).


pgpxVMScCegPo.pgp
Description: PGP signature

xconfig request

[Randy Dunlap]

Hi,

I have a UI request for xconfig.  Seems somewhat simple & obvious
from a user perspective.  I'm not saying that it's simple to
implement, but maybe someone out there would be interested in doing
so.


By default all menus start as open or expanded, but they can also be
closed by clicking on the "[-]" to the left of the menu heading,
to reduce the amount of screen real estate that the menu occupies.
However, when the parent menu is left (when the user moves to another
parent menu), the open/closed state of the user-requested-closed menu
is lost, so that when its parent menu is clicked/opened again, the
previously closed sub-menu is also open/expanded rather than closed.

The UI request is simply for menus that the user has requested to be
closed (unexpanded), they remain that way until the user clicks on the
"[+]" to open them.


Many examples are possible.  Here's one:

Go to the Networking menu and then cliick on "Networking options".
Click on the "[-]" to the left of "TCP/IP networking" because it takes
too much screen space.
Disable IPX and Appletalk below TCP/IP (this is just a pretend
scenario).
Now click on "Network device support".  Oops, forgot something in
the Networking menu, so click on Networking + "Networking options".
Darn, the TCP/IP networking menu is expanded again, using up all that
valuable screen space.


(maybe I just need a bigger screen :)

---
~Randy
Phaedrus says that Quality is about caring.
-
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.23-rc6-mm1 - make access to tasks nsproxy ligther (fix)

[Serge E. Hallyn]

Quoting Cedric Le Goater ([EMAIL PROTECTED]):
> Cedric Le Goater wrote:
> > Pavel Emelyanov wrote:
> >> Looks sane :)
> >>
> >> [snip]
> >>
> >>> Index: 2.6.23-rc6-mm1/kernel/exit.c
> >>> ===
> >>> --- 2.6.23-rc6-mm1.orig/kernel/exit.c
> >>> +++ 2.6.23-rc6-mm1/kernel/exit.c
> >>> @@ -408,6 +408,8 @@ void daemonize(const char *name, ...)
> >>>   current->fs = fs;
> >>>   atomic_inc(>count);
> >>>  
> >>> + if (current->nsproxy != init_task.nsproxy)
> >>> + get_nsproxy(init_task.nsproxy);
> >>>   switch_task_namespaces(current, init_task.nsproxy);
> >> shouldn't we make the switch under this if() as well?
> > 
> > right. we can probably simplify switch_task_namespaces() and remove :
> > 
> > if (ns == new)
> > return;
> > 
> > I'll cook a better one today.
> 
> So I removed this test in
> 
> * daemonize() bc it is already done 
> * sys_unshare() bc the nsproxy is always new one 
> * exit_task_namespaces() bc it is called with NULL and the
>   task will die right after that.
> 
> C.
> 
> 
> make-access-to-tasks-nsproxy-lighter.patch breaks unshare()
> 
> when called from unshare(), switch_task_namespaces() takes an 
> extra refcount on the nsproxy, leading to a memory leak of 
> nsproxy objects. 
> 
> Now the problem is that we still need that extra ref when called 
> from daemonize(). Here's an ugly fix for it.
> 
> Signed-off-by: Cedric Le Goater <[EMAIL PROTECTED]>
> Cc: Serge E. Hallyn <[EMAIL PROTECTED]>

Looks good.  Thanks for catching the leak.

Acked-by: Serge E. Hallyn <[EMAIL PROTECTED]>

> Cc: Pavel Emelyanov <[EMAIL PROTECTED]>
> Cc: Eric W. Biederman <[EMAIL PROTECTED]>
> Cc: Oleg Nesterov <[EMAIL PROTECTED]>
> Cc: Paul E. McKenney <[EMAIL PROTECTED]>
> 
> ---
>  include/linux/nsproxy.h |5 +
>  kernel/exit.c   |5 -
>  kernel/nsproxy.c|9 -
>  3 files changed, 9 insertions(+), 10 deletions(-)
> 
> Index: 2.6.23-rc6-mm1/kernel/nsproxy.c
> ===
> --- 2.6.23-rc6-mm1.orig/kernel/nsproxy.c
> +++ 2.6.23-rc6-mm1/kernel/nsproxy.c
> @@ -25,11 +25,6 @@ static struct kmem_cache *nsproxy_cachep
> 
>  struct nsproxy init_nsproxy = INIT_NSPROXY(init_nsproxy);
> 
> -static inline void get_nsproxy(struct nsproxy *ns)
> -{
> - atomic_inc(>count);
> -}
> -
>  /*
>   * creates a copy of "orig" with refcount 1.
>   */
> @@ -205,11 +200,7 @@ void switch_task_namespaces(struct task_
>   might_sleep();
> 
>   ns = p->nsproxy;
> - if (ns == new)
> - return;
> 
> - if (new)
> - get_nsproxy(new);
>   rcu_assign_pointer(p->nsproxy, new);
> 
>   if (ns && atomic_dec_and_test(>count)) {
> Index: 2.6.23-rc6-mm1/kernel/exit.c
> ===
> --- 2.6.23-rc6-mm1.orig/kernel/exit.c
> +++ 2.6.23-rc6-mm1/kernel/exit.c
> @@ -408,7 +408,10 @@ void daemonize(const char *name, ...)
>   current->fs = fs;
>   atomic_inc(>count);
> 
> - switch_task_namespaces(current, init_task.nsproxy);
> + if (current->nsproxy != init_task.nsproxy) {
> + get_nsproxy(init_task.nsproxy);
> + switch_task_namespaces(current, init_task.nsproxy);
> + }
> 
>   exit_files(current);
>   current->files = init_task.files;
> Index: 2.6.23-rc6-mm1/include/linux/nsproxy.h
> ===
> --- 2.6.23-rc6-mm1.orig/include/linux/nsproxy.h
> +++ 2.6.23-rc6-mm1/include/linux/nsproxy.h
> @@ -77,6 +77,11 @@ static inline void put_nsproxy(struct ns
>   }
>  }
> 
> +static inline void get_nsproxy(struct nsproxy *ns)
> +{
> + atomic_inc(>count);
> +}
> +
>  #ifdef CONFIG_CONTAINER_NS
>  int ns_container_clone(struct task_struct *tsk);
>  #else
-
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: Ethernet driver on 2.6.22

[Randy Dunlap]

On Mon, 24 Sep 2007 12:40:07 +1000 hce wrote:

> Thanks Randy.
> 
> On 9/24/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > On Mon, 24 Sep 2007 08:52:36 +1000 hce wrote:
> >
> > > Hi,
> > >
> > > I am upgrading from kernel 2.6.11 to 2.6.22 on ARM S3C2400A and found
> > > a following issue on 2.6.22.
> > >
> > > On 2.6.11, I selected CONFIG_ISA,  CONFIG_NET_PCI and CONFIG_CS89X0 to
> > > build  CS8900A Ethernet driver to kernel, it was running perfect.
> > >
> > > But on 2.6.22, I made the same configuration for CS8900A, the cs89x0.o
> > > could not be compiled in to the kernel (or as a module when I tried to
> > > CONFIG_CS89X0=m) unless I commented out depends statement in
> > > drivers/net/Kconfig. I double checked all three are CONFIG_ISA=y,
> > > CONFIG_NET_PCI=y and CONFIG_CS89X0=y. Any explanation please, was I
> > > missing something here?
> >
> > I didn't look in 2.6.11 Kconfig files, but in 2.6.22, this driver is
> > limited to 3 specific boards:
> >
> > config CS89x0
> > tristate "CS89x0 support"
> > depends on NET_PCI && (ISA || MACH_IXDP2351 || ARCH_IXDP2X01 || 
> > ARCH_PNX010X)
> 
> The Kconfig for CS89x0 in 2.6.11 is exactly the same as 2.6.22.
> 
> > Does ARM S3C2400A qualify as any of those?  (MACH_... or ARCH_...)
> 
> I can run CS89x0 for ARM S3C2400 in 2.6.11, at least I can say yes,
> the ARM S3C2400A qualifies those in 2.6.11, I don't know the 2.6.22
> and I hope someone knows 2.6.22 well can answer it.
> 
> > (latter: ARCH_PNX010X is not used anywhere else AFAICT)
> 
> Yes, but you only need to enable ISA and NET_PCI to use CS89x0.

Right.

I don't have any problem building CS89x0 for X86_32:
make defconfig then enable ISA (what!?!?  why not in defconfig?)
and then enable CS89x0.

Please send your .config file.

---
~Randy
Phaedrus says that Quality is about caring.
-
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: X-freeze after clflush changes [Was: 2.6.23-rc6-mm1]

[Valdis . Kletnieks]

On Fri, 21 Sep 2007 21:43:20 +0200, Jiri Slaby said:
> On 09/21/2007 09:38 PM, Jiri Slaby wrote:
> > It is rather the other user who adds the page to some other list while bein
g at
> > deferred_pages list. Could you try my debug patch
> > (http://lkml.org/lkml/2007/9/19/141)?
> 
> or the whitespace non-damaged version:
> http://www.fi.muni.cz/~xslaby/sklad/pageattr_debug

Gaak. Is that thing *supposed* to spew zillions of lines of output?

Some of the hits we get (I'm wondering if anything after the first makes
any sense, or if we're just slowly watching the corruption spread - the
thing ended up near 23K lines long before I gave up and hit the poweroff
button because there was no end in sight):

(If there's something specific you want me to find in the output,
like "the first time we see XYZ", yell...)

[  103.701000] POISONS (81000117dc88): 810006d14000, 8100034225c0
[  103.701000]
[  103.701000] Call Trace:
[  103.701000]  [] __list_add+0xd7/0x138
[  103.701000]  [] list_add+0xc/0x11
[  103.701000]  [] free_hot_cold_page+0xe8/0x16d
[  103.701000]  [] free_hot_page+0xb/0xd
[  103.701000]  [] __free_pages+0x18/0x21
[  103.701000]  [] free_pages+0x2f/0x34
[  103.701000]  [] kmem_freepages+0xc5/0xce
[  103.701000]  [] slab_destroy+0x3c/0x53
[  103.701000]  [] free_block+0xcd/0x110
[  103.701000]  [] drain_array+0x94/0xc9
[  103.701000]  [] cache_reap+0x0/0x105
[  103.701000]  [] cache_reap+0x85/0x105
[  103.701000]  [] run_workqueue+0x8e/0x125
[  103.701000]  [] worker_thread+0x0/0xe7
[  103.701000]  [] worker_thread+0xdc/0xe7
[  103.701000]  [] autoremove_wake_function+0x0/0x38
[  103.701000]  [] kthread+0x49/0x78
[  103.701000]  [] child_rip+0xa/0x12
[  103.701000]  [] kthread+0x0/0x78
[  103.701000]  [] child_rip+0x0/0x12
[  103.701000]

[  103.701000] POISONS (81000117eac0): 810006d55000, 8100034225c0
[  103.701000]
[  103.701000] Call Trace:
[  103.701000]  [] __list_add+0xd7/0x138
[  103.701000]  [] list_add+0xc/0x11
[  103.701000]  [] free_hot_cold_page+0xe8/0x16d
[  103.701000]  [] free_hot_page+0xb/0xd
[  103.701000]  [] __free_pages+0x18/0x21
[  103.701000]  [] free_pages+0x2f/0x34
[  103.701000]  [] kmem_freepages+0xc5/0xce
[  103.701000]  [] slab_destroy+0x3c/0x53
[  103.701000]  [] free_block+0xcd/0x110
[  103.701000]  [] drain_array+0x94/0xc9
[  103.701000]  [] cache_reap+0x0/0x105
[  103.701000]  [] cache_reap+0x85/0x105
[  103.701000]  [] run_workqueue+0x8e/0x125
[  103.701000]  [] worker_thread+0x0/0xe7
[  103.701000]  [] worker_thread+0xdc/0xe7
[  103.701000]  [] autoremove_wake_function+0x0/0x38
[  103.701000]  [] kthread+0x49/0x78
[  103.701000]  [] child_rip+0xa/0x12
[  103.701000]  [] kthread+0x0/0x78
[  103.701000]  [] child_rip+0x0/0x12
[  103.701000]
(That trace repeats 16 times, then we see:)
[  106.284000] POISONS (810004432810): 810005291378, 81000524e618
[  106.284000] 
[  106.284000] Call Trace:
[  106.284000]  [] __down_write_nested+0x3d/0xa1
[  106.284000]  [] __list_add+0xd7/0x138
[  106.284000]  [] vma_prio_tree_add+0xc9/0xe0
[  106.284000]  [] copy_process+0xc63/0x1515
[  106.284000]  [] do_fork+0x75/0x20b
[  106.284000]  [] __up_write+0xf0/0x100
[  106.284000]  [] system_call+0x7e/0x83
[  106.284000]  [] sys_clone+0x23/0x25
[  106.284000]  [] ptregscall_common+0x67/0xb0
[  106.284000] 
..
[  106.284000] POISONS (810004432768): 81000524e618, 81000524e618
[  106.284000]
[  106.284000] Call Trace:
[  106.284000]  [] __list_add+0xd7/0x138
[  106.284000]  [] vma_prio_tree_add+0xc9/0xe0
[  106.284000]  [] copy_process+0xc63/0x1515
[  106.284000]  [] do_fork+0x75/0x20b
[  106.284000]  [] __up_write+0xf0/0x100
[  106.284000]  [] system_call+0x7e/0x83
[  106.284000]  [] sys_clone+0x23/0x25
[  106.284000]  [] ptregscall_common+0x67/0xb0
[  106.284000]  
...
[  106.285000] POISONS (810003637b30): 810003637c18, 0246
[  106.285000]
[  106.285000] Call Trace:
[  106.285000]  [] __list_add+0xd7/0x138
[  106.285000]  [] list_add+0xc/0x11
[  106.285000]  [] add_wait_queue+0x2c/0x40
[  106.285000]  [] __pollwait+0xd6/0xdf
[  106.285000]  [] inotify_poll+0x29/0x5c
[  106.285000]  [] do_select+0x2fa/0x50d
[  106.285000]  [] __pollwait+0x0/0xdf
[  106.285000]  [] default_wake_function+0x0/0xf
[  106.285000]  [] __down_trylock+0x4d/0x5a
[  106.285000]  [] __down_failed_trylock+0x35/0x3a
[  106.285000]  [] __update_rq_clock+0x1a/0xe5
[  106.285000]  [] __alloc_pages+0x5c/0x2b5
[  106.285000]  [] core_sys_select+0x1f3/0x2a2
[  106.285000]  [] alloc_pid+0x2f8/0x34f
[  106.285000]  [] __up_read+0x7a/0x83
[  106.285000]  [] up_read+0x9/0xb
[  106.285000]  [] do_page_fault+0x405/0x7ac
[  106.285000]  [] sys_select+0xbf/0x17b
[  106.285000]  [] system_call+0x7e/0x83
[  106.285000] POISONS (810003637ba0): 8060ff48, 8051471d
[  106.285000]
[  106.285000] Call Trace:
[  106.285000]  [] __list_add+0xd7/0x138
[  106.285000]  [] list_add+0xc/0x11
[  106.285000]  [] add_wait_queue+0x2c/0x40
[  106.285000]  [] 

Re: Urgent bugzilla mainteinance needed

[Martin J. Bligh]

Natalie Protasevich wrote:

On 9/23/07, David Woodhouse <[EMAIL PROTECTED]> wrote:

On Sun, 2007-09-23 at 11:08 -0700, Natalie Protasevich wrote:

On 9/23/07, Diego Calleja <[EMAIL PROTECTED]> wrote:

Take a look at http://bugzilla.kernel.org/show_bug.cgi?id=3710

bugzilla tries to send a mail to the reporter, it fails ("unknown user 
account"),
but the error failure is appended as a bugzilla comment. Then bugzilla tries to
send that comment to everyone involved in the bug, including the reporter,
so it fails again.Houston, we've a endless loop.

There're 540 comments in that bug report already, and the bugme-daemon
mail list is being spammed

I just sent emails to those who maintain bugzilla software and systems
that run it, hope someone will be online soon to help alleviate
this...

Bugzilla really shouldn't be accepting any mail with empty reverse-path
(MAIL FROM:<>)


Ah, then should be easy fix then. I don't have access to the system
though, will have to helplessly wait until one of the guys picks up...
:(


Sorry, can't fix this - I don't have direct access to the system,
and I don't think the others will be back until Monday ;-(

M.
-
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.23-rc6-mm1 -- mkfs stuck in 'D'

[Fengguang Wu]

On Sun, Sep 23, 2007 at 03:02:35PM +0200, Peter Zijlstra wrote:
> On Sun, 23 Sep 2007 09:20:49 +0800 Fengguang Wu <[EMAIL PROTECTED]>
> wrote:
> 
> > On Sat, Sep 22, 2007 at 03:16:22PM +0200, Peter Zijlstra wrote:
> > > On Sat, 22 Sep 2007 09:55:09 +0800 Fengguang Wu <[EMAIL PROTECTED]>
> > > wrote:
> > > 
> > > > --- linux-2.6.22.orig/mm/page-writeback.c
> > > > +++ linux-2.6.22/mm/page-writeback.c
> > > > @@ -426,6 +426,14 @@ static void balance_dirty_pages(struct a
> > > > bdi_nr_writeback = bdi_stat(bdi, BDI_WRITEBACK);
> > > > }
> > > >  
> > > > +   printk(KERN_DEBUG "balance_dirty_pages written %lu %lu 
> > > > congested %d limits %lu %lu %lu %lu %lu %ld\n",
> > > > +   pages_written,
> > > > +   write_chunk - wbc.nr_to_write,
> > > > +   bdi_write_congested(bdi),
> > > > +   background_thresh, dirty_thresh,
> > > > +   bdi_thresh, bdi_nr_reclaimable, 
> > > > bdi_nr_writeback,
> > > > +   bdi_thresh - bdi_nr_reclaimable - 
> > > > bdi_nr_writeback);
> > > > +
> > > > if (bdi_nr_reclaimable + bdi_nr_writeback <= bdi_thresh)
> > > > break;
> > > > if (pages_written >= write_chunk)
> > > > 
> > > 
> > > > [ 1305.361511] balance_dirty_pages written 0 0 congested 0 limits 48869 
> > > > 195477 5801 5760 288 -247
> > > 
> > > 
> > > 
> > > Could you perhaps instrument the writeback_inodes() path to see why
> > > nothing is written out? - the attached patch would be a nice start.
> > 
> > Curiously the lockup problem disappeared after upgrading to 2.6.23-rc6-mm1.
> > (need to watch it in a longer time window).
> > 
> > Anyway here's the output of your patch:
> > sb_locked 0
> > sb_empty 97011
> 
> It this the delta during one of these lockups? If so, it would seem

delta since boot time, for 2.6.23-rc6-mm1, no lockups ;-)

> that although dirty pages are reported against the BDI, no actual dirty
> inodes could be found.

no lockups, therefore not necessarily.
There are many other calls into writeback_inodes().

> [ note to self: writeback_inodes() seems to write out to any superblock
>   in the system. Might want to limit that to superblocks on wbc->bdi ]

generic_sync_sb_inodes() does have something like:

if (wbc->bdi && bdi != wbc->bdi)
continue;

> You say that switching to .23-rc6-mm1 solved it in your case. You are
> developing in the writeback_inodes() path, right? Could it be one of
> your local changes that confused it here?

There are a lot of changes between them:
- bdi-v9 vs bdi-v10;
- a lot writeback patches in -mm
- some writeback patches maintained locally
I just rebased my patches to .23-rc6-mm1...

> > > Most peculiar. It seems writeback_inodes() doesn't even attempt to
> > > write out stuff. Nor are outstanding writeback pages completed.
> > 
> > Still true. Another problem is that balance_dirty_pages() is being called 
> > even
> > when there are only 54 dirty pages. That could slow down writers 
> > unnecessarily.
> > 
> > balance_dirty_pages() should not be entered at all with small nr_dirty.
> > 
> > Look at these lines:
> > [  197.471619] balance_dirty_pages for tar written 405 405 congested 0 
> > global 196554 54 403 196097 bdi 0 0 398 -398
> > [  197.472196] balance_dirty_pages for tar written 405 0 congested 0 global 
> > 196554 54 372 196128 bdi 0 0 380 -380
> > [  197.472893] balance_dirty_pages for tar written 405 0 congested 0 global 
> > 196554 54 372 196128 bdi 23 0 369 -346
> > [  197.473158] balance_dirty_pages for tar written 405 0 congested 0 global 
> > 196554 54 372 196128 bdi 23 0 366 -343
> > [  197.473403] balance_dirty_pages for tar written 405 0 congested 0 global 
> > 196554 54 372 196128 bdi 23 0 365 -342
> > [  197.473674] balance_dirty_pages for tar written 405 0 congested 0 global 
> > 196554 54 372 196128 bdi 23 0 364 -341
> > [  197.474265] balance_dirty_pages for tar written 405 0 congested 0 global 
> > 196554 54 372 196128 bdi 23 0 362 -339
> > [  197.475440] balance_dirty_pages for tar written 405 0 congested 0 global 
> > 196554 54 341 196159 bdi 47 0 327 -280
> > [  197.476970] balance_dirty_pages for tar written 405 0 congested 0 global 
> > 196546 54 279 196213 bdi 95 0 279 -184
> > [  197.43] balance_dirty_pages for tar written 405 0 congested 0 global 
> > 196546 54 248 196244 bdi 95 0 255 -160
> > [  197.479463] balance_dirty_pages for tar written 405 0 congested 0 global 
> > 196546 54 217 196275 bdi 143 0 210 -67
> > [  197.479656] balance_dirty_pages for tar written 405 0 congested 0 global 
> > 196546 54 217 196275 bdi 143 0 209 -66
> > [  197.481159] balance_dirty_pages for tar written 405 0 congested 0 global 
> > 196546 54 155 196337 bdi 167 0 163 4
> 
> That is an interesting idea 

[Resend][-mm Patch] net/bluetooth/hidp/core.c: Make hidp_setup_input() return int

[WANG Cong]

This patch does the following things:

- Make hidp_setup_input() return int to indicate errors.
- Check its return value to handle errors.

Thanks to roel for comments.
 
Signed-off-by: WANG Cong <[EMAIL PROTECTED]>

---
 net/bluetooth/hidp/core.c |   11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

Index: linux-2.6.23-rc6-mm1/net/bluetooth/hidp/core.c
===
--- linux-2.6.23-rc6-mm1.orig/net/bluetooth/hidp/core.c
+++ linux-2.6.23-rc6-mm1/net/bluetooth/hidp/core.c
@@ -625,7 +625,7 @@ static struct device *hidp_get_device(st
return conn ? >dev : NULL;
 }
 
-static inline void hidp_setup_input(struct hidp_session *session, struct 
hidp_connadd_req *req)
+static inline int hidp_setup_input(struct hidp_session *session, struct 
hidp_connadd_req *req)
 {
struct input_dev *input = session->input;
int i;
@@ -669,7 +669,7 @@ static inline void hidp_setup_input(stru
 
input->event = hidp_input_event;
 
-   input_register_device(input);
+   return input_register_device(input);
 }
 
 static int hidp_open(struct hid_device *hid)
@@ -822,8 +822,11 @@ int hidp_add_connection(struct hidp_conn
session->flags   = req->flags & (1 << HIDP_BLUETOOTH_VENDOR_ID);
session->idle_to = req->idle_to;
 
-   if (session->input)
-   hidp_setup_input(session, req);
+   if (session->input) {
+   err = hidp_setup_input(session, req);
+   if (err)
+   goto failed;
+   }
 
if (session->hid)
hidp_setup_hid(session, req);
-
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: [-mm Patch] net/bluetooth/hidp/core.c: Make hidp_setup_input() return int

[WANG Cong]

On Mon, Sep 24, 2007 at 12:13:22AM +0200, roel wrote:
>WANG Cong wrote:
>> This patch does the following things:
>> 
>> - Make hidp_setup_input() return int to indicate errors.
>> - Check its return value to handle errors.
>> 
>> Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
>> 
>> ---
>>  net/bluetooth/hidp/core.c |7 ---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>> 
>> Index: linux-2.6.23-rc6-mm1/net/bluetooth/hidp/core.c
>> ===
>> --- linux-2.6.23-rc6-mm1.orig/net/bluetooth/hidp/core.c
>> +++ linux-2.6.23-rc6-mm1/net/bluetooth/hidp/core.c
>> @@ -625,7 +625,7 @@ static struct device *hidp_get_device(st
>>  return conn ? >dev : NULL;
>>  }
>>  
>> -static inline void hidp_setup_input(struct hidp_session *session, struct 
>> hidp_connadd_req *req)
>> +static inline int hidp_setup_input(struct hidp_session *session, struct 
>> hidp_connadd_req *req)
>>  {
>>  struct input_dev *input = session->input;
>>  int i;
>> @@ -669,7 +669,7 @@ static inline void hidp_setup_input(stru
>>  
>>  input->event = hidp_input_event;
>>  
>> -input_register_device(input);
>> +return input_register_device(input);
>>  }
>>  
>>  static int hidp_open(struct hid_device *hid)
>> @@ -823,7 +823,8 @@ int hidp_add_connection(struct hidp_conn
>>  session->idle_to = req->idle_to;
>>  
>>  if (session->input)
>> -hidp_setup_input(session, req);
>> +if ((err = (hidp_setup_input(session, req
>> +goto failed;
>
>This is confusing, why not just do
>
>   if (session->input) {
>   err = hidp_setup_input(session, req);
>   if (err)
>   goto failed;
>   }

Yes, you are right. Thanks. I will resend this patch. ;)

-- 
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

-
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: Ethernet driver on 2.6.22

[hce]

Thanks Randy.

On 9/24/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Mon, 24 Sep 2007 08:52:36 +1000 hce wrote:
>
> > Hi,
> >
> > I am upgrading from kernel 2.6.11 to 2.6.22 on ARM S3C2400A and found
> > a following issue on 2.6.22.
> >
> > On 2.6.11, I selected CONFIG_ISA,  CONFIG_NET_PCI and CONFIG_CS89X0 to
> > build  CS8900A Ethernet driver to kernel, it was running perfect.
> >
> > But on 2.6.22, I made the same configuration for CS8900A, the cs89x0.o
> > could not be compiled in to the kernel (or as a module when I tried to
> > CONFIG_CS89X0=m) unless I commented out depends statement in
> > drivers/net/Kconfig. I double checked all three are CONFIG_ISA=y,
> > CONFIG_NET_PCI=y and CONFIG_CS89X0=y. Any explanation please, was I
> > missing something here?
>
> I didn't look in 2.6.11 Kconfig files, but in 2.6.22, this driver is
> limited to 3 specific boards:
>
> config CS89x0
> tristate "CS89x0 support"
> depends on NET_PCI && (ISA || MACH_IXDP2351 || ARCH_IXDP2X01 || 
> ARCH_PNX010X)

The Kconfig for CS89x0 in 2.6.11 is exactly the same as 2.6.22.

> Does ARM S3C2400A qualify as any of those?  (MACH_... or ARCH_...)

I can run CS89x0 for ARM S3C2400 in 2.6.11, at least I can say yes,
the ARM S3C2400A qualifies those in 2.6.11, I don't know the 2.6.22
and I hope someone knows 2.6.22 well can answer it.

> (latter: ARCH_PNX010X is not used anywhere else AFAICT)

Yes, but you only need to enable ISA and NET_PCI to use CS89x0.

> ---
> ~Randy
> Phaedrus says that Quality is about caring.
>

Thank you.

Kind regards,

Jim
-
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] GEODE: decouple sleep/resume from powerdown/powerup (take 2)

[Bernardo Innocenti]

This patch merges the fb_powerup and fb_powerdown hooks in a single
operation fb_power with an additional "state" parameter ranging
from 0 (running) to 3 (poweroff).

The geodefb uses state 2 as an intermediate low-power mode, where
the LX or GX video unit is turned off, but the GPU may still be working.
Notably, the GPU register set does not get overwritten when resuming
to state 0, so the system can safely keep using the GPU while in state 2.
The DCON driver now uses this new suspend state to let the X server draw
in the background while the screen frozen.

This fixes the rather amusing OLPC bug #3603 that made the toolbar icons
come up tinted in green when "pretty boot" was enabled.  Tested on both
B2 (GX) and B3 (LX) machines.  Both the freeze/unfreeze and suspend/resume
codepaths work as expected.

This second revision ensures the GX registers are saved in both the
suspend and powerdown cases, otherwise we restore stale register state
when we unfreeze.

Signed-off-by: Bernardo Innocenti <[EMAIL PROTECTED]>
---
 drivers/video/fbmem.c   |   47 +--
 drivers/video/geode/geodefb.h   |   13 +++--
 drivers/video/geode/gxfb_core.c |   17 +++
 drivers/video/geode/lxfb.h  |3 +-
 drivers/video/geode/lxfb_core.c |   12 ++---
 drivers/video/geode/lxfb_ops.c  |   47 
 drivers/video/geode/video_gx.c  |   94 --
 drivers/video/geode/video_gx.h  |3 +-
 drivers/video/olpc_dcon.c   |8 ++--
 include/linux/fb.h  |7 +--
 10 files changed, 110 insertions(+), 141 deletions(-)

diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 61d7659..51c9f79 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -736,49 +736,28 @@ static void try_to_load(int fb)
 #endif /* CONFIG_KMOD */
 
 int
-fb_powerup(struct fb_info *info)
+fb_power(struct fb_info *info, int state)
 {
int ret = 0;
 
-   if (!info || info->state == FBINFO_STATE_RUNNING)
-   return 0;
-
-   if (info->fbops->fb_powerup)
-   ret = info->fbops->fb_powerup(info);
-
-   if (!ret) {
-   acquire_console_sem();
-   fb_set_suspend(info, 0);
-   release_console_sem();
-   }
-
-   return ret;
-}
-
-int
-fb_powerdown(struct fb_info *info)
-{
-   int ret = 0;
-
-   if (!info || info->state == FBINFO_STATE_SUSPENDED)
-   return 0;
+   if (state < 0 || state > 3)
+   return -EINVAL;
 
-   /* Tell everybody that the fbdev is going down */
acquire_console_sem();
-   fb_set_suspend(info, 1);
-   release_console_sem();
+   /* Powerdown? */
+   if (state == 3 && info->state != FBINFO_STATE_SUSPENDED)
+   /* Tell everybody that the fbdev is going down */
+   fb_set_suspend(info, 1);
 
-   if (info->fbops->fb_powerdown)
-   ret = info->fbops->fb_powerdown(info);
+   if (info->fbops->fb_power)
+   ret = info->fbops->fb_power(info, state);
 
-   /* If the power down failed, then un-notify */
-
-   if (ret) {
-   acquire_console_sem();
+   /* Power down failed, or powerup succeeded? */
+   if (((state == 3 && ret) || !ret) && (info->state != 
FBINFO_STATE_RUNNING))
+   /* Tell everybody that the fbdev is back up */
fb_set_suspend(info, 0);
-   release_console_sem();
-   }
 
+   release_console_sem();
return ret;
 }
 
diff --git a/drivers/video/geode/geodefb.h b/drivers/video/geode/geodefb.h
index 0214d11..cd1ce6e 100644
--- a/drivers/video/geode/geodefb.h
+++ b/drivers/video/geode/geodefb.h
@@ -12,12 +12,14 @@
 #ifndef __GEODEFB_H__
 #define __GEODEFB_H__
 
-#define FB_POWER_STATE_OFF  0
-#define FB_POWER_STATE_SUSPEND  1
-#define FB_POWER_STATE_ON   2
-
 struct geodefb_info;
 
+/* For geodefb_par->power_state */
+#define FB_POWER_STATE_OFF  3
+#define FB_POWER_STATE_SUSPEND  2
+#define FB_POWER_STATE_UNUSED   1 /* Reserved */
+#define FB_POWER_STATE_ON   0
+
 struct geode_dc_ops {
void (*set_mode)(struct fb_info *);
void (*set_palette_reg)(struct fb_info *, unsigned, unsigned, unsigned, 
unsigned);
@@ -42,7 +44,8 @@ struct geodefb_par {
struct geode_dc_ops  *dc_ops;
struct geode_vid_ops *vid_ops;
 
-   int state;
+   /* See FB_POWER_STATE_* definitions above */
+   int power_state;
 };
 
 #endif /* !__GEODEFB_H__ */
diff --git a/drivers/video/geode/gxfb_core.c b/drivers/video/geode/gxfb_core.c
index 3eabc53..cd43c8e 100644
--- a/drivers/video/geode/gxfb_core.c
+++ b/drivers/video/geode/gxfb_core.c
@@ -383,8 +383,7 @@ static struct fb_ops gxfb_ops = {
.fb_fillrect= cfb_fillrect,
.fb_copyarea= cfb_copyarea,
.fb_imageblit   = cfb_imageblit,
-   .fb_powerdown   = gxfb_powerdown,
-   .fb_powerup = gxfb_powerup,
+   .fb_power   = gxfb_power,
 };
 
 static 

Re: Re: [PATCH] ahci: Add MCP79 support to AHCI driver

[Peer Chen]

Code change, remove some Device IDs.

Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
---
--- linux-2.6.23-rc7/drivers/ata/ahci.c.orig2007-09-20 11:01:55.0 
-0400
+++ linux-2.6.23-rc7/drivers/ata/ahci.c 2007-09-24 10:08:03.0 -0400
@@ -472,6 +472,14 @@ static const struct pci_device_id ahci_p
{ PCI_VDEVICE(NVIDIA, 0x0ad9), board_ahci },/* MCP77 */
{ PCI_VDEVICE(NVIDIA, 0x0ada), board_ahci },/* MCP77 */
{ PCI_VDEVICE(NVIDIA, 0x0adb), board_ahci },/* MCP77 */
+   { PCI_VDEVICE(NVIDIA, 0x0ab8), board_ahci },/* MCP79 */
+   { PCI_VDEVICE(NVIDIA, 0x0ab9), board_ahci },/* MCP79 */
+   { PCI_VDEVICE(NVIDIA, 0x0aba), board_ahci },/* MCP79 */
+   { PCI_VDEVICE(NVIDIA, 0x0abb), board_ahci },/* MCP79 */
+   { PCI_VDEVICE(NVIDIA, 0x0abc), board_ahci },/* MCP79 */
+   { PCI_VDEVICE(NVIDIA, 0x0abd), board_ahci },/* MCP79 */
+   { PCI_VDEVICE(NVIDIA, 0x0abe), board_ahci },/* MCP79 */
+   { PCI_VDEVICE(NVIDIA, 0x0abf), board_ahci },/* MCP79 */
 
/* SiS */
{ PCI_VDEVICE(SI, 0x1184), board_ahci }, /* SiS 966 */
-

--   
Peer Chen
2007-09-24

-
·¢¼þÈË£ºAlan Cox
·¢ËÍÈÕÆÚ£º2007-09-21 18:32:09
ÊÕ¼þÈË£ºPeer Chen
³­ËÍ£ºlinux-kernel; linux-ide; akpm; jeff
Ö÷Ì⣺Re: [PATCH] ahci: Add MCP79 support to AHCI driver

On Fri, 21 Sep 2007 14:06:10 +0800
"Peer Chen" <[EMAIL PROTECTED]> wrote:

> Add the MCP79 support to ahci driver.
> The patch base on kernel 2.6.23-rc7

Is this actually needed or as they are standard ahci devices will the
class match get them anyway ?

-
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: Re: [PATCH] ahci: Add MCP79 support to AHCI driver

[Peer Chen]

Yes,it's necessary because our RAID controller also use the ahci driver.

--   
Peer Chen
2007-09-24

-
·¢¼þÈË£ºAlan Cox
·¢ËÍÈÕÆÚ£º2007-09-21 18:32:09
ÊÕ¼þÈË£ºPeer Chen
³­ËÍ£ºlinux-kernel; linux-ide; akpm; jeff
Ö÷Ì⣺Re: [PATCH] ahci: Add MCP79 support to AHCI driver

On Fri, 21 Sep 2007 14:06:10 +0800
"Peer Chen" <[EMAIL PROTECTED]> wrote:

> Add the MCP79 support to ahci driver.
> The patch base on kernel 2.6.23-rc7

Is this actually needed or as they are standard ahci devices will the
class match get them anyway ?

-
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: Ethernet driver on 2.6.22

[Randy Dunlap]

On Mon, 24 Sep 2007 08:52:36 +1000 hce wrote:

> Hi,
> 
> I am upgrading from kernel 2.6.11 to 2.6.22 on ARM S3C2400A and found
> a following issue on 2.6.22.
> 
> On 2.6.11, I selected CONFIG_ISA,  CONFIG_NET_PCI and CONFIG_CS89X0 to
> build  CS8900A Ethernet driver to kernel, it was running perfect.
> 
> But on 2.6.22, I made the same configuration for CS8900A, the cs89x0.o
> could not be compiled in to the kernel (or as a module when I tried to
> CONFIG_CS89X0=m) unless I commented out depends statement in
> drivers/net/Kconfig. I double checked all three are CONFIG_ISA=y,
> CONFIG_NET_PCI=y and CONFIG_CS89X0=y. Any explanation please, was I
> missing something here?

I didn't look in 2.6.11 Kconfig files, but in 2.6.22, this driver is
limited to 3 specific boards:

config CS89x0
tristate "CS89x0 support"
depends on NET_PCI && (ISA || MACH_IXDP2351 || ARCH_IXDP2X01 || 
ARCH_PNX010X)

Does ARM S3C2400A qualify as any of those?  (MACH_... or ARCH_...)

(latter: ARCH_PNX010X is not used anywhere else AFAICT)

---
~Randy
Phaedrus says that Quality is about caring.
-
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 RFC 3/9] RCU: Preemptible RCU

[Paul E. McKenney]

On Sun, Sep 23, 2007 at 09:38:07PM +0400, Oleg Nesterov wrote:
> On 09/10, Paul E. McKenney wrote:
> >
> > Work in progress, not for inclusion.
> 
> Impressive work! a couple of random newbie's questions...

Thank you for the kind words, and most especially for the careful review!!!

And Oleg, I don't think you qualify as a newbie anymore.  ;-)

> > --- linux-2.6.22-b-fixbarriers/include/linux/rcupdate.h 2007-07-19 
> > 14:02:36.0 -0700
> > +++ linux-2.6.22-c-preemptrcu/include/linux/rcupdate.h  2007-08-22 
> > 15:21:06.0 -0700
> >
> >  extern void rcu_check_callbacks(int cpu, int user);
> 
> Also superfluously declared in rcuclassic.h and in rcupreempt.h

Definitely are two of them in rcupdate.h, good eyes!  The ones in
rcuclassic.h and rcupreempt.h, by the time all the patches are
applied, are for rcu_check_callbacks_rt().  However, this, along
with the other _rt() cross-calls from rcuclassic.c to rcupreempt.c,
will go away when the merge with upcoming hotplug patches is complete.

> > --- linux-2.6.22-b-fixbarriers/include/linux/rcupreempt.h   1969-12-31 
> > 16:00:00.0 -0800
> > +++ linux-2.6.22-c-preemptrcu/include/linux/rcupreempt.h2007-08-22 
> > 15:21:06.0 -0700
> > +
> > +#define __rcu_read_lock_nesting()  (current->rcu_read_lock_nesting)
> 
> unused?

It would seem so!  Will remove it.

> > diff -urpNa -X dontdiff linux-2.6.22-b-fixbarriers/kernel/rcupreempt.c 
> > linux-2.6.22-c-preemptrcu/kernel/rcupreempt.c
> > --- linux-2.6.22-b-fixbarriers/kernel/rcupreempt.c  1969-12-31 
> > 16:00:00.0 -0800
> > +++ linux-2.6.22-c-preemptrcu/kernel/rcupreempt.c   2007-08-22 
> > 15:35:19.0 -0700
> >
> > +static DEFINE_PER_CPU(struct rcu_data, rcu_data);
> > +static struct rcu_ctrlblk rcu_ctrlblk = {
> > +   .fliplock = SPIN_LOCK_UNLOCKED,
> > +   .completed = 0,
> > +};
> > static DEFINE_PER_CPU(int [2], rcu_flipctr) = { 0, 0 };
> 
> Just curious, any reason why rcu_flipctr can't live in rcu_data ? Similarly,
> rcu_try_flip_state can be a member of rcu_ctrlblk, it is even protected by
> rcu_ctrlblk.fliplock

In the case of rcu_flipctr, this is historical -- the implementation in
-rt has only one rcu_data, rather than one per CPU.  I cannot think of
a problem with placing it in rcu_data right off-hand, will look it over
carefully and see.

Good point on rcu_try_flip_state!!!

> Isn't DEFINE_PER_CPU_SHARED_ALIGNED better for rcu_flip_flag and rcu_mb_flag?

Looks like it to me, thank you for the tip!

Hmmm...  Why not the same for rcu_data?  I guess because there is
very little sharing?  The only example thus far of sharing would be
if rcu_flipctr were to be moved into rcu_data (if an RCU read-side
critical section were preempted and then started on some other CPU),
though I will need to check more carefully.

Of course, if we start having CPUs access each others' rcu_data structures
to make RCU more power-friendly in dynticks situations, then maybe there
would be more reason to use DEFINE_PER_CPU_SHARED_ALIGNED for rcu_data.

Thoughts?

> > +void __rcu_read_lock(void)
> > +{
> > +   int idx;
> > +   struct task_struct *me = current;
> > +   int nesting;
> > +
> > +   nesting = ORDERED_WRT_IRQ(me->rcu_read_lock_nesting);
> > +   if (nesting != 0) {
> > +
> > +   /* An earlier rcu_read_lock() covers us, just count it. */
> > +
> > +   me->rcu_read_lock_nesting = nesting + 1;
> > +
> > +   } else {
> > +   unsigned long oldirq;
> > +
> > +   /*
> > +* Disable local interrupts to prevent the grace-period
> > +* detection state machine from seeing us half-done.
> > +* NMIs can still occur, of course, and might themselves
> > +* contain rcu_read_lock().
> > +*/
> > +
> > +   local_irq_save(oldirq);
> 
> Could you please tell more, why do we need this cli?
> 
> It can't "protect" rcu_ctrlblk.completed, and the only change which affects
> the state machine is rcu_flipctr[idx]++, so I can't understand the "half-done"
> above. (of course, we must disable preemption while changing rcu_flipctr).
> 
> Hmm... this was already discussed... from another message:
> 
>   > Critical portions of the GP protection happen in the scheduler-clock
>   > interrupt, which is a hardirq.  For example, the .completed counter
>   > is always incremented in hardirq context, and we cannot tolerate a
>   > .completed increment in this code.  Allowing such an increment would
>   > defeat the counter-acknowledge state in the state machine.
> 
> Still can't understand, please help! .completed could be incremented by
> another CPU, why rcu_check_callbacks() running on _this_ CPU is so special?

Yeah, I guess my explanation -was- a bit lacking...  When I re-read it, it
didn't even help -me- much!  ;-)

I am putting together better documentation, but in the meantime, let me
try again...

The problem is not with .completed being incremented, but only
by it 

Re: [PATCH] Broadcom 8603 SAS/SATA driver, rough draft

[Jeff Garzik]

James Bottomley wrote:

On Sun, 2007-09-23 at 19:43 -0400, Jeff Garzik wrote:

James Bottomley wrote:

On Sun, 2007-09-23 at 00:04 -0400, Jeff Garzik wrote:

Rather than sitting on this for far too long, I wanted to go ahead and
get this out there.  I heard some chips might be trickling out into
public hands.

The first thing to note is about the specs and the pre-production
hardware: the Linux Foundation has mechanism to get both into the hands
of interested developers; if you can point me to contacts, I can at
least get the NDA documentation programme ball rolling.

Well, are there interested, motivated, skilled developers with time?  :)

Otherwise it's a moot point.


We have GregKH's minions ... this would be a good project for them.



Same answer ... GregKH has a legion ... lets use it.


This is a good project for somebody who knows how SAS behaves on the 
wire, which is a rather limited group.


I'm willing to help anyone who proactively moves in this direction, but 
they need to be proactive about it...  I am the person who will have to 
make introductions at Broadcom, and convince Broadcom that new Person is 
a highly capable SAS software engineer.


Telling bcm "I don't know this guy, its doubtful he knows SAS, but we 
want to make him the primary engineer anyway" is not a very winning tale :)



SMP and STP, by the way, are simple frame in, frame out.  If it
identifies the initiator and target protocols and allows us to send
frames, we can probably transmit both protocols.

[...]

That's going to be a bit of a bit oops ...

[...]

well, I suppose it was designed for simple direct connection ...


That's the way it's looking.  There are a few avenues for exposing 
IDENTIFY and OPEN frames and related details, but no obvious "any frame, 
no problem" method like with the Marvell chip.


IMO it's also indicative that Marvell's chip uses a single set of 
command and response queues, whereas Broadcom has command/response 
queues for each "port" (bcm's term).


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: 2.6.23-rc7 + radeonfb/s2ram

[Benjamin Herrenschmidt]

On Sun, 2007-09-23 at 23:31 +0200, Oleg Verych wrote:
> * Sun, 23 Sep 2007 22:22:28 +0300
> * Organization: Home
> 
> []
> >> > 
> >> >   So there, if one wants "ATI Radeon display support" on Radeon XPRESS 
> >> > 200M with
> >> >   X using radeon_drv.so, *should* put "Framebuffer Console support" to N 
> >> > (if it's
> >> >   not already).
> []
> >   Bottom line: no radeonfb for me :( at least, not now; but I have to be 
> > honest with
> >   you: I don't see what commit dd1447134454b169d5ae353aceb93f2368db8547 
> > brought new
> >   into the picture. The previous radeonfb worked just great, but then, 
> > again, maybe I'm
> >   not using the console at it's full power :)
> 
> In fact, it's known statement, that there must only one hardware driver
> for graphic adapter. Be it framebuffer with X fb driver on it or legacy
> VGA text and X with its driver.so and 3D stuff.
> 
> (i choose legacy text without X for the most of my time, though :)

Not quite ... on PowerMacs, we've been routinely using radeonfb and X
together. However, for that to work, in general, one has to be careful
to switch back to console mode before suspending and back to X after
resume, which seems to have been broken by many distro lately, probably
because somebody made it optional in the kernel...

Ben.


-
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.23-rc7 + radeonfb/s2ram

[Benjamin Herrenschmidt]

On Sun, 2007-09-23 at 22:22 +0300, Mihai Donțu wrote:
> 
>   Bottom line: no radeonfb for me :( at least, not now; but I have to
> be honest with
>   you: I don't see what commit
> dd1447134454b169d5ae353aceb93f2368db8547 brought new
>   into the picture. The previous radeonfb worked just great, but then,
> again, maybe I'm
>   not using the console at it's full power :)

It might have simply not initialized :-)

Ben.


-
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] Broadcom 8603 SAS/SATA driver, rough draft

[James Bottomley]

On Sun, 2007-09-23 at 19:43 -0400, Jeff Garzik wrote:
> James Bottomley wrote:
> > On Sun, 2007-09-23 at 00:04 -0400, Jeff Garzik wrote:
> >> Rather than sitting on this for far too long, I wanted to go ahead and
> >> get this out there.  I heard some chips might be trickling out into
> >> public hands.
> > 
> > The first thing to note is about the specs and the pre-production
> > hardware: the Linux Foundation has mechanism to get both into the hands
> > of interested developers; if you can point me to contacts, I can at
> > least get the NDA documentation programme ball rolling.
> 
> Well, are there interested, motivated, skilled developers with time?  :)
> 
> Otherwise it's a moot point.

We have GregKH's minions ... this would be a good project for them.

> >> This is a bare bones Broadcom 8603 SAS+SATA driver, attempting to use
> >> the vaunted libsas.  Notes:
> > 
> > I wouldn't call it "vaunted" but it's been a fun project.
> 
> That was sarcasm :)
> 
> libsas is a big 'ole pain, that I'm finding has many aic94xx-isms buried 
> in the lib.

Well, that's hardly surprising ... it was written by Adaptec and there
was no other device to help with its production.

> >> * A quick glance at the FIXMEs will tell you obviously doesn't work.
> > 
> > The first thing I really noted is that SMP and STP protocol support is
> > stubbed out ... you really can't do anything other than direct device
> > connection without them.
> 
> That's sorta the way I read the hardware docs, too.
> 
> I have some engineering questions pending with Broadcom, but from my 
> read, SMP and STP don't seem supported.

That would effectively render the device pretty much useless.  The maing
benefit of SAS is that you can support expanders, which are the
predominant connection infrastructure.  Direct connect SAS is OK, but
SATA tends to be cheaper.

> >> * The hardware is quite simple and straightforward and easy to program
> >>   in an efficient way:  each SAS port has a command queue (DMA ring) and
> >>   a response queue (DMA ring).  Or if in SATA mode, just a command
> >>   queue.
> > 
> > That's not such a bad way of doing it ... it pretty much mimics the wire
> > protocol, which is simply frame in/frame out for SAS.
> 
> Yep.  The hardware (on my end of the spectrum) seems to be moving 
> towards forcing software to generate all "packets," except (a) data 
> frames [generated via DMA engine] or (b) special frames that need to 
> modify the software-generate frame.

SMP and STP, by the way, are simple frame in, frame out.  If it
identifies the initiator and target protocols and allows us to send
frames, we can probably transmit both protocols.

> >> * The SAS/SATA negotiation is largely out of our hands.  The silicon
> >>   does its thing, and then tells us what type of device connected.  We
> >>   are then expected to switch the port to either SAS mode or SATA mode,
> >>   accordingly.
> >>
> >> * There is no firmware or anything.  Just DMA and register bitbanging.
> >>   We have plenty of low-level control.
> >>
> >> * The state of SAS/SATA integration is perpetually pathetic.  Updates
> >>   in this area are likely.  There's a rumor Brian King @ IBM may look
> >>   into this area too.
> >>
> >> * This driver pretty much completely lacks exception handling.
> > 
> > I also note there's a slight nomenclature issue which will trip up SAS
> > people.  All through the driver, you seem to use the word "port" to
> > refer to a physical phy.  the struct bs_port seems to actually be a phy
> > descriptor ... unless there's some missing phy<->port setup logic that
> > will be in the final driver?  The trouble is that phys and ports are
> > distinct (and not equivalent) objects in SAS.
> 
> Nomemclature came straight from the hardware docs, I'm afraid.
> 
> Comparing with the Marvell hardware, I can see how (with Marvell) wide 
> ports can be set up, and the port/phy distinction is easily programmable 
> depending on the situation.
> 
> Not so with BCM8603.

That's going to be a bit of a bit oops ...

> The only places where the docs mention SMP and STP at all is in the SAS 
> outgoing DMA descriptor docs, when you fill in connection type.  The 
> _only_ other mention of SMP or STP at all is a note saying neither is 
> supported.  So, even the docs contradict themselves, but overall I have 
> the feeling that SMP/STP are out of my hands.

Heh, well, I suppose it was designed for simple direct connection ...

> I wonder if Broadcom's interface is born out of the closed RAID-on-chip 
> product that this is descended from.
> 
> Hopefully more knowledge will be gained soon, as I debug simple SAS and 
> SATA device plug/unplug, and ask Broadcom questions.
> 
> 
> >> As an aside, I am also writing a driver for Marvell chips that behave
> >> quite similarly to this chip.  It seems the future of storage might look
> >> like these Broadcom and Marvell SAS+SATA DMA ring interfaces, in the
> >> volume marketspace at least.
> > 
> > If you have a 

Re: [PATCH] Broadcom 8603 SAS/SATA driver, rough draft

[Jeff Garzik]

Jeff Garzik wrote:
Just for everybody's information, the Marvell SAS/SATA chip for which 
I'm also writing a driver definitely supports all of that:  SMP, STP, 
wire ports, SCSI target mode, even SATA target mode.


s/wire/wide/ of course

-
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] Broadcom 8603 SAS/SATA driver, rough draft

[Jeff Garzik]

Douglas Gilbert wrote:

Is the lack of SMP support a driver limitation or is it
the silicon?

How about support for wide ports (i.e. when 2 or more HBA
phys are attached to remote phys which have the same SAS
addresses)?

Last question: can the chip run in SCSI target mode?



Just for everybody's information, the Marvell SAS/SATA chip for which 
I'm also writing a driver definitely supports all of that:  SMP, STP, 
wire ports, SCSI target mode, even SATA target mode.


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: [PATCH] Broadcom 8603 SAS/SATA driver, rough draft

[Jeff Garzik]

James Bottomley wrote:

On Sun, 2007-09-23 at 00:04 -0400, Jeff Garzik wrote:

Rather than sitting on this for far too long, I wanted to go ahead and
get this out there.  I heard some chips might be trickling out into
public hands.


The first thing to note is about the specs and the pre-production
hardware: the Linux Foundation has mechanism to get both into the hands
of interested developers; if you can point me to contacts, I can at
least get the NDA documentation programme ball rolling.


Well, are there interested, motivated, skilled developers with time?  :)

Otherwise it's a moot point.



This is a bare bones Broadcom 8603 SAS+SATA driver, attempting to use
the vaunted libsas.  Notes:


I wouldn't call it "vaunted" but it's been a fun project.


That was sarcasm :)

libsas is a big 'ole pain, that I'm finding has many aic94xx-isms buried 
in the lib.




* A quick glance at the FIXMEs will tell you obviously doesn't work.


The first thing I really noted is that SMP and STP protocol support is
stubbed out ... you really can't do anything other than direct device
connection without them.


That's sorta the way I read the hardware docs, too.

I have some engineering questions pending with Broadcom, but from my 
read, SMP and STP don't seem supported.




* The hardware is quite simple and straightforward and easy to program
  in an efficient way:  each SAS port has a command queue (DMA ring) and
  a response queue (DMA ring).  Or if in SATA mode, just a command
  queue.


That's not such a bad way of doing it ... it pretty much mimics the wire
protocol, which is simply frame in/frame out for SAS.


Yep.  The hardware (on my end of the spectrum) seems to be moving 
towards forcing software to generate all "packets," except (a) data 
frames [generated via DMA engine] or (b) special frames that need to 
modify the software-generate frame.




* The SAS/SATA negotiation is largely out of our hands.  The silicon
  does its thing, and then tells us what type of device connected.  We
  are then expected to switch the port to either SAS mode or SATA mode,
  accordingly.

* There is no firmware or anything.  Just DMA and register bitbanging.
  We have plenty of low-level control.

* The state of SAS/SATA integration is perpetually pathetic.  Updates
  in this area are likely.  There's a rumor Brian King @ IBM may look
  into this area too.

* This driver pretty much completely lacks exception handling.


I also note there's a slight nomenclature issue which will trip up SAS
people.  All through the driver, you seem to use the word "port" to
refer to a physical phy.  the struct bs_port seems to actually be a phy
descriptor ... unless there's some missing phy<->port setup logic that
will be in the final driver?  The trouble is that phys and ports are
distinct (and not equivalent) objects in SAS.


Nomemclature came straight from the hardware docs, I'm afraid.

Comparing with the Marvell hardware, I can see how (with Marvell) wide 
ports can be set up, and the port/phy distinction is easily programmable 
depending on the situation.


Not so with BCM8603.

The only places where the docs mention SMP and STP at all is in the SAS 
outgoing DMA descriptor docs, when you fill in connection type.  The 
_only_ other mention of SMP or STP at all is a note saying neither is 
supported.  So, even the docs contradict themselves, but overall I have 
the feeling that SMP/STP are out of my hands.


I wonder if Broadcom's interface is born out of the closed RAID-on-chip 
product that this is descended from.


Hopefully more knowledge will be gained soon, as I debug simple SAS and 
SATA device plug/unplug, and ask Broadcom questions.




As an aside, I am also writing a driver for Marvell chips that behave
quite similarly to this chip.  It seems the future of storage might look
like these Broadcom and Marvell SAS+SATA DMA ring interfaces, in the
volume marketspace at least.


If you have a contact here too, I can get the LF NDA and hardware
programmes rolling.


Same response as at the top :)  Marvell is actually better at responding 
than Broadcom, but I'm quite reluctant to make /another/ introduction 
(already did so for one hacker) that leads nowhere.


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: [PATCH] Broadcom 8603 SAS/SATA driver, rough draft

[Jeff Garzik]

Douglas Gilbert wrote:

Is the lack of SMP support a driver limitation or is it
the silicon?


Open question (pending w/ BCM).  It looks like the answer is "silicon 
limitation".




How about support for wide ports


Open question (w/ BCM).  It looks like the answer is "no support."



Last question: can the chip run in SCSI target mode?


AFAICT, no.

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/

[PATCH] GEODE: decouple sleep/resume from powerdown/powerup

[Bernardo Innocenti]

This patch merges the fb_powerup and fb_powerdown hooks in a single
operation fb_power with an additional "state" parameter ranging
from 0 (running) to 3 (poweroff).

The geodefb uses state 2 as an intermediate low-power mode, where
the LX or GX video unit is turned off, but the GPU may still be working.
Notably, the GPU register set does not get overwritten when resuming
to state 0, so the system can safely keep using the GPU while in state 2.
The DCON driver now uses this new suspend state to let the X server draw
in the background while the screen frozen.

This fixes the rather amusing OLPC bug #3603 that made the toolbar icons
come up tinted in green when "pretty boot" was enabled.  Tested on both
B2 (GX) and B3 (LX) machines.  Both the freeze/unfreeze and suspend/resume
codepaths work as expected.

Signed-off-by: Bernardo Innocenti <[EMAIL PROTECTED]>
---
 drivers/video/fbmem.c   |   47 +--
 drivers/video/geode/geodefb.h   |   13 +++--
 drivers/video/geode/gxfb_core.c |   17 +++
 drivers/video/geode/lxfb.h  |3 +-
 drivers/video/geode/lxfb_core.c |   12 ++---
 drivers/video/geode/lxfb_ops.c  |   47 +++
 drivers/video/geode/video_gx.c  |   97 +--
 drivers/video/geode/video_gx.h  |3 +-
 drivers/video/olpc_dcon.c   |8 ++--
 include/linux/fb.h  |7 +--
 10 files changed, 112 insertions(+), 142 deletions(-)

diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 61d7659..51c9f79 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -736,49 +736,28 @@ static void try_to_load(int fb)
 #endif /* CONFIG_KMOD */
 
 int
-fb_powerup(struct fb_info *info)
+fb_power(struct fb_info *info, int state)
 {
int ret = 0;
 
-   if (!info || info->state == FBINFO_STATE_RUNNING)
-   return 0;
-
-   if (info->fbops->fb_powerup)
-   ret = info->fbops->fb_powerup(info);
-
-   if (!ret) {
-   acquire_console_sem();
-   fb_set_suspend(info, 0);
-   release_console_sem();
-   }
-
-   return ret;
-}
-
-int
-fb_powerdown(struct fb_info *info)
-{
-   int ret = 0;
-
-   if (!info || info->state == FBINFO_STATE_SUSPENDED)
-   return 0;
+   if (state < 0 || state > 3)
+   return -EINVAL;
 
-   /* Tell everybody that the fbdev is going down */
acquire_console_sem();
-   fb_set_suspend(info, 1);
-   release_console_sem();
+   /* Powerdown? */
+   if (state == 3 && info->state != FBINFO_STATE_SUSPENDED)
+   /* Tell everybody that the fbdev is going down */
+   fb_set_suspend(info, 1);
 
-   if (info->fbops->fb_powerdown)
-   ret = info->fbops->fb_powerdown(info);
+   if (info->fbops->fb_power)
+   ret = info->fbops->fb_power(info, state);
 
-   /* If the power down failed, then un-notify */
-
-   if (ret) {
-   acquire_console_sem();
+   /* Power down failed, or powerup succeeded? */
+   if (((state == 3 && ret) || !ret) && (info->state != 
FBINFO_STATE_RUNNING))
+   /* Tell everybody that the fbdev is back up */
fb_set_suspend(info, 0);
-   release_console_sem();
-   }
 
+   release_console_sem();
return ret;
 }
 
diff --git a/drivers/video/geode/geodefb.h b/drivers/video/geode/geodefb.h
index 0214d11..cd1ce6e 100644
--- a/drivers/video/geode/geodefb.h
+++ b/drivers/video/geode/geodefb.h
@@ -12,12 +12,14 @@
 #ifndef __GEODEFB_H__
 #define __GEODEFB_H__
 
-#define FB_POWER_STATE_OFF  0
-#define FB_POWER_STATE_SUSPEND  1
-#define FB_POWER_STATE_ON   2
-
 struct geodefb_info;
 
+/* For geodefb_par->power_state */
+#define FB_POWER_STATE_OFF  3
+#define FB_POWER_STATE_SUSPEND  2
+#define FB_POWER_STATE_UNUSED   1 /* Reserved */
+#define FB_POWER_STATE_ON   0
+
 struct geode_dc_ops {
void (*set_mode)(struct fb_info *);
void (*set_palette_reg)(struct fb_info *, unsigned, unsigned, unsigned, 
unsigned);
@@ -42,7 +44,8 @@ struct geodefb_par {
struct geode_dc_ops  *dc_ops;
struct geode_vid_ops *vid_ops;
 
-   int state;
+   /* See FB_POWER_STATE_* definitions above */
+   int power_state;
 };
 
 #endif /* !__GEODEFB_H__ */
diff --git a/drivers/video/geode/gxfb_core.c b/drivers/video/geode/gxfb_core.c
index 3eabc53..cd43c8e 100644
--- a/drivers/video/geode/gxfb_core.c
+++ b/drivers/video/geode/gxfb_core.c
@@ -383,8 +383,7 @@ static struct fb_ops gxfb_ops = {
.fb_fillrect= cfb_fillrect,
.fb_copyarea= cfb_copyarea,
.fb_imageblit   = cfb_imageblit,
-   .fb_powerdown   = gxfb_powerdown,
-   .fb_powerup = gxfb_powerup,
+   .fb_power   = gxfb_power,
 };
 
 static struct fb_info * __init gxfb_init_fbinfo(struct device *dev)
@@ -452,13 +451,13 @@ static int gxfb_suspend(struct pci_dev *pdev,  
pm_message_t state)
 

Re: [PATCH] Broadcom 8603 SAS/SATA driver, rough draft

[James Bottomley]

On Sun, 2007-09-23 at 00:04 -0400, Jeff Garzik wrote:
> Rather than sitting on this for far too long, I wanted to go ahead and
> get this out there.  I heard some chips might be trickling out into
> public hands.

The first thing to note is about the specs and the pre-production
hardware: the Linux Foundation has mechanism to get both into the hands
of interested developers; if you can point me to contacts, I can at
least get the NDA documentation programme ball rolling.

> This is a bare bones Broadcom 8603 SAS+SATA driver, attempting to use
> the vaunted libsas.  Notes:

I wouldn't call it "vaunted" but it's been a fun project.

> * A quick glance at the FIXMEs will tell you obviously doesn't work.

The first thing I really noted is that SMP and STP protocol support is
stubbed out ... you really can't do anything other than direct device
connection without them.

> * The hardware is quite simple and straightforward and easy to program
>   in an efficient way:  each SAS port has a command queue (DMA ring) and
>   a response queue (DMA ring).  Or if in SATA mode, just a command
>   queue.

That's not such a bad way of doing it ... it pretty much mimics the wire
protocol, which is simply frame in/frame out for SAS.

> * The SAS/SATA negotiation is largely out of our hands.  The silicon
>   does its thing, and then tells us what type of device connected.  We
>   are then expected to switch the port to either SAS mode or SATA mode,
>   accordingly.
> 
> * There is no firmware or anything.  Just DMA and register bitbanging.
>   We have plenty of low-level control.
> 
> * The state of SAS/SATA integration is perpetually pathetic.  Updates
>   in this area are likely.  There's a rumor Brian King @ IBM may look
>   into this area too.
> 
> * This driver pretty much completely lacks exception handling.

I also note there's a slight nomenclature issue which will trip up SAS
people.  All through the driver, you seem to use the word "port" to
refer to a physical phy.  the struct bs_port seems to actually be a phy
descriptor ... unless there's some missing phy<->port setup logic that
will be in the final driver?  The trouble is that phys and ports are
distinct (and not equivalent) objects in SAS.

> As an aside, I am also writing a driver for Marvell chips that behave
> quite similarly to this chip.  It seems the future of storage might look
> like these Broadcom and Marvell SAS+SATA DMA ring interfaces, in the
> volume marketspace at least.

If you have a contact here too, I can get the LF NDA and hardware
programmes rolling.

James


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

Ethernet driver on 2.6.22

[hce]

Hi,

I am upgrading from kernel 2.6.11 to 2.6.22 on ARM S3C2400A and found
a following issue on 2.6.22.

On 2.6.11, I selected CONFIG_ISA,  CONFIG_NET_PCI and CONFIG_CS89X0 to
build  CS8900A Ethernet driver to kernel, it was running perfect.

But on 2.6.22, I made the same configuration for CS8900A, the cs89x0.o
could not be compiled in to the kernel (or as a module when I tried to
CONFIG_CS89X0=m) unless I commented out depends statement in
drivers/net/Kconfig. I double checked all three are CONFIG_ISA=y,
CONFIG_NET_PCI=y and CONFIG_CS89X0=y. Any explanation please, was I
missing something here?

Thank you.

Regards,

Jim
-
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] new timerfd API - un-break CONFIG_TIMERFD

[Davide Libenzi]

Remove the broken status to CONFIG_TIMERFD.



Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>


- Davide


---
 init/Kconfig |1 -
 1 file changed, 1 deletion(-)

Index: linux-2.6.mod/init/Kconfig
===
--- linux-2.6.mod.orig/init/Kconfig 2007-09-23 15:18:06.0 -0700
+++ linux-2.6.mod/init/Kconfig  2007-09-23 15:28:54.0 -0700
@@ -488,7 +488,6 @@
 config TIMERFD
bool "Enable timerfd() system call" if EMBEDDED
select ANON_INODES
-   depends on BROKEN
default y
help
  Enable the timerfd() system call that allows to receive timer

-
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] new timerfd API - new timerfd API

[Davide Libenzi]

This is the new timerfd API as it is implemented by the following patch:

int timerfd_create(int clockid);
int timerfd_settime(int ufd, int flags,
const struct itimerspec *utmr,
struct itimerspec *otmr);
int timerfd_gettime(int ufd, struct itimerspec *otmr);

The timerfd_create() API creates an un-programmed timerfd fd. The "clockid"
parameter can be either CLOCK_MONOTONIC or CLOCK_REALTIME.
The timerfd_settime() API give new settings by the timerfd fd, by optionally
retrieving the previous expiration time (in case the "otmr" parameter is not 
NULL).
The time value specified in "utmr" is absolute, if the TFD_TIMER_ABSTIME bit
is set in the "flags" parameter. Otherwise it's a relative time.
The timerfd_gettime() API returns the next expiration time of the timer, or {0, 
0}
if the timerfd has not been set yet.
Like the previous timerfd API implementation, read(2) and poll(2) are supported
(with the same interface).
Here's a simple test program I used to exercise the new timerfd APIs:

http://www.xmailserver.org/timerfd-test2.c



Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>


- Davide


---
 fs/compat.c  |   32 ++-
 fs/timerfd.c |  199 ++-
 include/linux/compat.h   |7 +
 include/linux/syscalls.h |7 +
 4 files changed, 168 insertions(+), 77 deletions(-)

Index: linux-2.6.mod/fs/timerfd.c
===
--- linux-2.6.mod.orig/fs/timerfd.c 2007-09-23 15:18:09.0 -0700
+++ linux-2.6.mod/fs/timerfd.c  2007-09-23 15:25:55.0 -0700
@@ -23,15 +23,17 @@
 
 struct timerfd_ctx {
struct hrtimer tmr;
+   int clockid;
ktime_t tintv;
wait_queue_head_t wqh;
int expired;
+   u64 ticks;
 };
 
 /*
  * This gets called when the timer event triggers. We set the "expired"
  * flag, but we do not re-arm the timer (in case it's necessary,
- * tintv.tv64 != 0) until the timer is read.
+ * tintv.tv64 != 0) until the timer is accessed.
  */
 static enum hrtimer_restart timerfd_tmrproc(struct hrtimer *htmr)
 {
@@ -40,13 +42,14 @@
 
spin_lock_irqsave(>wqh.lock, flags);
ctx->expired = 1;
+   ctx->ticks++;
wake_up_locked(>wqh);
spin_unlock_irqrestore(>wqh.lock, flags);
 
return HRTIMER_NORESTART;
 }
 
-static void timerfd_setup(struct timerfd_ctx *ctx, int clockid, int flags,
+static void timerfd_setup(struct timerfd_ctx *ctx, int flags,
  const struct itimerspec *ktmr)
 {
enum hrtimer_mode htmode;
@@ -57,8 +60,9 @@
 
texp = timespec_to_ktime(ktmr->it_value);
ctx->expired = 0;
+   ctx->ticks = 0;
ctx->tintv = timespec_to_ktime(ktmr->it_interval);
-   hrtimer_init(>tmr, clockid, htmode);
+   hrtimer_init(>tmr, ctx->clockid, htmode);
ctx->tmr.expires = texp;
ctx->tmr.function = timerfd_tmrproc;
if (texp.tv64 != 0)
@@ -83,7 +87,7 @@
poll_wait(file, >wqh, wait);
 
spin_lock_irqsave(>wqh.lock, flags);
-   if (ctx->expired)
+   if (ctx->ticks)
events |= POLLIN;
spin_unlock_irqrestore(>wqh.lock, flags);
 
@@ -102,11 +106,11 @@
return -EINVAL;
spin_lock_irq(>wqh.lock);
res = -EAGAIN;
-   if (!ctx->expired && !(file->f_flags & O_NONBLOCK)) {
+   if (!ctx->ticks && !(file->f_flags & O_NONBLOCK)) {
__add_wait_queue(>wqh, );
for (res = 0;;) {
set_current_state(TASK_INTERRUPTIBLE);
-   if (ctx->expired) {
+   if (ctx->ticks) {
res = 0;
break;
}
@@ -121,22 +125,23 @@
__remove_wait_queue(>wqh, );
__set_current_state(TASK_RUNNING);
}
-   if (ctx->expired) {
-   ctx->expired = 0;
-   if (ctx->tintv.tv64 != 0) {
+   if (ctx->ticks) {
+   ticks = ctx->ticks;
+   if (ctx->expired && ctx->tintv.tv64) {
/*
 * If tintv.tv64 != 0, this is a periodic timer that
 * needs to be re-armed. We avoid doing it in the timer
 * callback to avoid DoS attacks specifying a very
 * short timer period.
 */
-   ticks = (u64)
+   ticks += (u64)
hrtimer_forward(>tmr,
hrtimer_cb_get_time(>tmr),
-   ctx->tintv);
+   ctx->tintv) - 1;
hrtimer_restart(>tmr);
-   } else
-   ticks = 1;
+   }
+   ctx->expired = 0;
+   

[patch 2/3] new timerfd API - wire the new timerfd API to the x86 family

[Davide Libenzi]

Wires up the new timerfd API to the x86 family.



Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>


- Davide


---
 arch/i386/kernel/syscall_table.S |5 -
 arch/x86_64/ia32/ia32entry.S |4 +++-
 include/asm-i386/unistd.h|6 --
 include/asm-x86_64/unistd.h  |8 ++--
 4 files changed, 17 insertions(+), 6 deletions(-)

Index: linux-2.6.mod/arch/i386/kernel/syscall_table.S
===
--- linux-2.6.mod.orig/arch/i386/kernel/syscall_table.S 2007-09-23 
15:28:48.0 -0700
+++ linux-2.6.mod/arch/i386/kernel/syscall_table.S  2007-09-23 
15:28:52.0 -0700
@@ -321,6 +321,9 @@
.long sys_epoll_pwait
.long sys_utimensat /* 320 */
.long sys_signalfd
-   .long sys_timerfd
+   .long sys_timerfd_create
.long sys_eventfd
.long sys_fallocate
+   .long sys_timerfd_settime   /* 325 */
+   .long sys_timerfd_gettime
+
Index: linux-2.6.mod/arch/x86_64/ia32/ia32entry.S
===
--- linux-2.6.mod.orig/arch/x86_64/ia32/ia32entry.S 2007-09-23 
15:28:48.0 -0700
+++ linux-2.6.mod/arch/x86_64/ia32/ia32entry.S  2007-09-23 15:28:52.0 
-0700
@@ -730,7 +730,9 @@
.quad sys_epoll_pwait
.quad compat_sys_utimensat  /* 320 */
.quad compat_sys_signalfd
-   .quad compat_sys_timerfd
+   .quad sys_timerfd_create
.quad sys_eventfd
.quad sys32_fallocate
+   .quad compat_sys_timerfd_settime/* 325 */
+   .quad compat_sys_timerfd_gettime
 ia32_syscall_end:
Index: linux-2.6.mod/include/asm-i386/unistd.h
===
--- linux-2.6.mod.orig/include/asm-i386/unistd.h2007-09-23 
15:28:48.0 -0700
+++ linux-2.6.mod/include/asm-i386/unistd.h 2007-09-23 15:28:52.0 
-0700
@@ -327,13 +327,15 @@
 #define __NR_epoll_pwait   319
 #define __NR_utimensat 320
 #define __NR_signalfd  321
-#define __NR_timerfd   322
+#define __NR_timerfd_create322
 #define __NR_eventfd   323
 #define __NR_fallocate 324
+#define __NR_timerfd_settime   325
+#define __NR_timerfd_gettime   326
 
 #ifdef __KERNEL__
 
-#define NR_syscalls 325
+#define NR_syscalls 327
 
 #define __ARCH_WANT_IPC_PARSE_VERSION
 #define __ARCH_WANT_OLD_READDIR
Index: linux-2.6.mod/include/asm-x86_64/unistd.h
===
--- linux-2.6.mod.orig/include/asm-x86_64/unistd.h  2007-09-23 
15:28:48.0 -0700
+++ linux-2.6.mod/include/asm-x86_64/unistd.h   2007-09-23 15:28:52.0 
-0700
@@ -626,12 +626,16 @@
 __SYSCALL(__NR_epoll_pwait, sys_epoll_pwait)
 #define __NR_signalfd  282
 __SYSCALL(__NR_signalfd, sys_signalfd)
-#define __NR_timerfd   283
-__SYSCALL(__NR_timerfd, sys_timerfd)
+#define __NR_timerfd_create283
+__SYSCALL(__NR_timerfd_create, sys_timerfd_create)
 #define __NR_eventfd   284
 __SYSCALL(__NR_eventfd, sys_eventfd)
 #define __NR_fallocate 285
 __SYSCALL(__NR_fallocate, sys_fallocate)
+#define __NR_timerfd_settime   286
+__SYSCALL(__NR_timerfd_settime, sys_timerfd_settime)
+#define __NR_timerfd_gettime   287
+__SYSCALL(__NR_timerfd_gettime, sys_timerfd_gettime)
 
 #ifndef __NO_STUBS
 #define __ARCH_WANT_OLD_READDIR

-
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: Coding FATX support for 2.6

[Hector Martin]

Diego Calleja wrote:
> FUSE could be an acceptable solution.

Not really. Booting Xbox-Linux from an image file on a FATX partition is
common. I don't think FUSE would work very well there.


-- 
Hector Martin ([EMAIL PROTECTED])
Public Key: http://www.marcansoft.com/marcan.asc

-
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: Coding FATX support for 2.6

[Diego Calleja]

El Sun, 23 Sep 2007 16:51:15 -0400, Hector Martin <[EMAIL PROTECTED]> escribió:

> Most xbox-linux users are stuck using 2.4, since there is no FATX driver
> for 2.6 and the 2.4 one is unmaintained. I've been thinking about
> writing FATX support into 2.6, to finally end this problem (this is
> basically the only thing holding up 2.6 for Xbox Linux distros). While I
> have done a little kernel coding in the past, I've never messed with
> filesystems in Linux and I'm not entirely sure what the best approach
> would be here. I would like to do it in such a way that it can be

FUSE could be an acceptable solution.
-
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/

Xen kernel 2.6.23-rc7 bug at xen_mc_flush (arch/i386/xen/multicalls.c:68)

[osth]

Using kernel 2.6.23-rc7 as xen domU client system I observe a kernel bug
which occurs reproducibly when calling a shell from midnight commander F2
context menu or with testcase given below  (However most other programs seem
to
be well behaved and do not trigger this bug). - A kernel compiled with debug
info gives:

Kernel BUG at c01037dc [verbose debug info unavailable]
invalid opcode:  [#5]
PREEMPT SMP
...
Call Trace:
[] <0> [] <0> [] <0> [] <0> []
<0> [] <0> [] <0> ===
...
gdb) l *0xc01037dc
0xc01037dc is in xen_mc_flush (arch/i386/xen/multicalls.c:68).
63  } else
64  BUG_ON(b->argidx != 0);
65
66  local_irq_restore(flags);
67
68  BUG_ON(ret);
69  }
0xc0103de9 is in xen_exit_mmap (arch/i386/xen/multicalls.h:42).
0xc015d1d1 is in exit_mmap (include/asm/paravirt.h:722).
0xc0190078 is in load_script (fs/binfmt_script.c:19).
0xc012633e is in mmput (kernel/fork.c:395).
0xc016fa54 is in do_execve (fs/exec.c:1421).
0xc0106547 is in sys_execve (arch/i386/kernel/process.c:793).
No source file for address 0xc01080d2.

/proc/cpuinfo: ...AMD Athlon(tm) X2 Dual Core Processor BE-2350 ...

full info is at http://spblinux.de/xen/20070923/

Same bug if preempt is disabled; same bug if vcpus is reduced to 1 in xen
domU.

Please cc to osth at freesurf.ch because I am not on the list.

Christian Ostheimer

testcase which triggers the bug:

#!/bin/bash
#
# modified configure script: max commandline length test
CONFIG_SHELL=/bin/bash
i=0
export teststring=ABCD
while (test "X"`$CONFIG_SHELL -c "echo X$teststring" 2>/dev/null` \
   = "XX$teststring") >/dev/null 2>&1 &&
new_result=`expr "X$teststring" : ".*" 2>&1` &&
lt_cv_sys_max_cmd_len=$new_result &&
test $i != 17 # 1/2 MB should be enough
do 
  i=`expr $i + 1`
  teststring=$teststring$teststring
done
teststring=
# Add a significant safety factor because C++ compilers can tack on massive
# amounts of additional arguments before passing them to the linker.
# It appears as though 1/2 is a usable value.
echo `expr $lt_cv_sys_max_cmd_len \/ 2`


Neu: Das erste ADSL-Abo ohne Monatsgebühr! Steigen Sie jetzt auf sunrise
ADSL free um.
http://www.sunrise.ch/privatkunden/iminternetsurfen/adsl/adsl_abosundpreise/adsl_gelegenheitssurfer/adsl_free.htm



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

Linux 2.4.35.3

[Willy Tarreau]

I've just released Linux 2.4.35.3.

This version fixes CVE-2007-4573 which may lead to local privilege escalation
on x86_64.

It also fixes another problem reported by Gilles Espinasse: If the ATM module
is loaded with CLIP support but the CLIP module is not loaded yet, any user
reading /proc/net/atm/arp would cause a kernel panic to occur. 

Both x86_64 and ATM users are encouraged to upgrade. Note that USB DSL modems
often use ATM.

The patch and changelog will appear soon at the following locations:
  ftp://ftp.all.kernel.org/pub/linux/kernel/v2.4/
  ftp://ftp.all.kernel.org/pub/linux/kernel/v2.4/patch-2.4.35.3.bz2
  ftp://ftp.all.kernel.org/pub/linux/kernel/v2.4/ChangeLog-2.4.35.3

Git repository:
   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-v2.4.35.y.git
  http://www.kernel.org/pub/scm/linux/kernel/git/stable/linux-v2.4.35.y.git

Git repository through the gitweb interface:
  http://git.kernel.org/?p=linux/kernel/git/stable/linux-v2.4.35.y.git

Willy

---

Summary of changes from v2.4.35.2 to v2.4.35.3


Andi Kleen (1):
  x86_64: Make sure to validate all 64bits of ptrace information

Stephen Hemminger (1):
  Bridge STP timer fixes

Willy Tarreau (2):
  ATM: avoid kernel panic upon access to /proc/net/atm/arp
  Change VERSION to 2.4.35.3

-
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: [-mm Patch] net/bluetooth/hidp/core.c: Make hidp_setup_input() return int

[roel]

WANG Cong wrote:
> This patch does the following things:
> 
> - Make hidp_setup_input() return int to indicate errors.
> - Check its return value to handle errors.
> 
> Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
> 
> ---
>  net/bluetooth/hidp/core.c |7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> Index: linux-2.6.23-rc6-mm1/net/bluetooth/hidp/core.c
> ===
> --- linux-2.6.23-rc6-mm1.orig/net/bluetooth/hidp/core.c
> +++ linux-2.6.23-rc6-mm1/net/bluetooth/hidp/core.c
> @@ -625,7 +625,7 @@ static struct device *hidp_get_device(st
>   return conn ? >dev : NULL;
>  }
>  
> -static inline void hidp_setup_input(struct hidp_session *session, struct 
> hidp_connadd_req *req)
> +static inline int hidp_setup_input(struct hidp_session *session, struct 
> hidp_connadd_req *req)
>  {
>   struct input_dev *input = session->input;
>   int i;
> @@ -669,7 +669,7 @@ static inline void hidp_setup_input(stru
>  
>   input->event = hidp_input_event;
>  
> - input_register_device(input);
> + return input_register_device(input);
>  }
>  
>  static int hidp_open(struct hid_device *hid)
> @@ -823,7 +823,8 @@ int hidp_add_connection(struct hidp_conn
>   session->idle_to = req->idle_to;
>  
>   if (session->input)
> - hidp_setup_input(session, req);
> + if ((err = (hidp_setup_input(session, req
> + goto failed;

This is confusing, why not just do

if (session->input) {
err = hidp_setup_input(session, req);
if (err)
goto failed;
}

>  
>   if (session->hid)
>   hidp_setup_hid(session, req);
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

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

Re: [PATCH] Broadcom 8603 SAS/SATA driver, rough draft

[Douglas Gilbert]

Jeff Garzik wrote:
> Rather than sitting on this for far too long, I wanted to go ahead and
> get this out there.  I heard some chips might be trickling out into
> public hands.
> 
> This is a bare bones Broadcom 8603 SAS+SATA driver, attempting to use
> the vaunted libsas.  Notes:
> 
> * A quick glance at the FIXMEs will tell you obviously doesn't work.
> 
> * The hardware is quite simple and straightforward and easy to program
>   in an efficient way:  each SAS port has a command queue (DMA ring) and
>   a response queue (DMA ring).  Or if in SATA mode, just a command
>   queue.
> 
> * The SAS/SATA negotiation is largely out of our hands.  The silicon
>   does its thing, and then tells us what type of device connected.  We
>   are then expected to switch the port to either SAS mode or SATA mode,
>   accordingly.
> 
> * There is no firmware or anything.  Just DMA and register bitbanging.
>   We have plenty of low-level control.
> 
> * The state of SAS/SATA integration is perpetually pathetic.  Updates
>   in this area are likely.  There's a rumor Brian King @ IBM may look
>   into this area too.
> 
> * This driver pretty much completely lacks exception handling.
> 
> 
> As an aside, I am also writing a driver for Marvell chips that behave
> quite similarly to this chip.  It seems the future of storage might look
> like these Broadcom and Marvell SAS+SATA DMA ring interfaces, in the
> volume marketspace at least.

Jeff,
Is the lack of SMP support a driver limitation or is it
the silicon?

How about support for wide ports (i.e. when 2 or more HBA
phys are attached to remote phys which have the same SAS
addresses)?

Last question: can the chip run in SCSI target mode?

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

Coding FATX support for 2.6

[Hector Martin]

Most xbox-linux users are stuck using 2.4, since there is no FATX driver
for 2.6 and the 2.4 one is unmaintained. I've been thinking about
writing FATX support into 2.6, to finally end this problem (this is
basically the only thing holding up 2.6 for Xbox Linux distros). While I
have done a little kernel coding in the past, I've never messed with
filesystems in Linux and I'm not entirely sure what the best approach
would be here. I would like to do it in such a way that it can be
included in mainline once it is complete. This would also be beneficial
for PC Linux distros, as it enables access to Xbox memory cards (needed
to soft-mod an Xbox to run Linux - currently users have to either use
Windows or boot an Xbox-Linux distro on their PC)

Here's a quick rundown of the differences between FAT and FATX:
- The superblock is different. FATX hardcodes or calculates most of the
parameters. All that is left in the superblock is a magic string and a
few basic parameters. For example, FATX calculates the number of
clusters, and therefore the size of the FAT, from the size of the
device. There is also no free block count present - this is instead
calculated by scanning the FAT (which can be slow for large partitions).
- The FAT itself is mostly the same, except for a few details regarding
the first few entries. FATX is also available in FATX16 and FATX32
variants. Which is in use depends on the size of the device. FATX32
actually uses all 32 bits in the FAT entries, instead of 28 bits like
FAT32 does.
- Directory entries are 64 bytes long. Filenames are up to 42 characters
long. There is no stupid long filename overlay hack like VFAT uses. File
extensions have no special place - filenames are simple unformatted
42-byte strings. Date/Times are the same, but the epoch is different.

I see several options for implementing this:
- Add support to the standard FAT driver. This should probably be made a
configurable suboption.
- Add support that piggybacks onto the standard FAT driver, but
otherwise doesn't touch it. I don't know how feasible this is.
- Modify the FAT driver to allow the basic changes needed to support
FATX, then piggyback it for the actual implementation. See above.
- Fork the FAT driver and make it into a FATX driver.
- Start from scratch.

I'm unsure about what the best option would be. Obviously changes to FAT
should be made with care, as we don't want to cause a regression.
However, much of the code (allocation strategies, FAT handling, etc)
should be the same or very similar, so it seems stupid to start from
scratch.

Comments?


-- 
Hector Martin ([EMAIL PROTECTED])
Public Key: http://www.marcansoft.com/marcan.asc

-
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.23-rc7 + radeonfb/s2ram

[Oleg Verych]

* Sun, 23 Sep 2007 22:22:28 +0300
* Organization: Home

[]
>> > 
>> >   So there, if one wants "ATI Radeon display support" on Radeon XPRESS 
>> > 200M with
>> >   X using radeon_drv.so, *should* put "Framebuffer Console support" to N 
>> > (if it's
>> >   not already).
[]
>   Bottom line: no radeonfb for me :( at least, not now; but I have to be 
> honest with
>   you: I don't see what commit dd1447134454b169d5ae353aceb93f2368db8547 
> brought new
>   into the picture. The previous radeonfb worked just great, but then, again, 
> maybe I'm
>   not using the console at it's full power :)

In fact, it's known statement, that there must only one hardware driver
for graphic adapter. Be it framebuffer with X fb driver on it or legacy
VGA text and X with its driver.so and 3D stuff.

(i choose legacy text without X for the most of my time, though :)
_
-
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/7] Extended crashkernel command line

[Bernhard Walle]

* Oleg Verych <[EMAIL PROTECTED]> [2007-09-23 23:15]:
> 
> - crashkernel=512M-2G:64M,2G-:[EMAIL PROTECTED]
> + crashkernel=512M-2G,64M,2G-,128M,,offset
> ?

I don't like this syntax.


Thanks,
   Bernhard
-
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/7] Extended crashkernel command line

[Oleg Verych]

On Sun, Sep 23, 2007 at 10:19:43PM +0200, Bernhard Walle wrote:
[]
> >  +int __init get_crashkernel_params(u64 *memsize, u64 *addrbase, char 
> > *cmdline, u64 ram);
> 
> Andrew, what's your opinion on this? Whould I resend the patch with
> shorter type names?

Also, maybe it will be better to extend linux/lib/cmdline.c->{get_range(), 
get_range()}
to handle that stuff? And maybe new functionality can be built up-on the 
current one: 

- crashkernel=512M-2G:64M,2G-:[EMAIL PROTECTED]
+ crashkernel=512M-2G,64M,2G-,128M,,offset
?

OK, OK, you are already using and maintaining new syntax, but still.
_
(`Mail-Followup-To' ignored)
-
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.23-rc4-mm1 and -rc6-mm1: boot failure on HP nx6325, related to clockevents

[Rafael J. Wysocki]

On Sunday, 23 September 2007 21:59, Thomas Gleixner wrote:
> On Sun, 2007-09-23 at 22:08 +0200, Rafael J. Wysocki wrote:
> > > > Since the boot fails very early, before any messages reach the (VGA) 
> > > > console,
> > > > I have no idea what to do next, except for digging in the code.
> > > 
> > > Ok, lets track it down. Is there any difference when you add:
> > > 
> > > nohz=off
> > > highres=off
> > > noapictimer
> > > 
> > > or any combinations of the above to the kernel command line ?
> > 
> > First, for now, I build all kernels with NO_HZ and HIGH_RES_TIMERS unset
> > (.config for 2.6.23-rc6-mm1 is attached).
> > 
> > Second, noacpitimer added to the command line makes all of the kernels, up 
> > to
> > and including 2.6.23-rc6-mm1, boot (this seems to be 100% reproducible).
> 
> That's valuable information. Can you please provide a boot log of one of
> those with an additional "apic=verbose" on the command line ?

Attached is the dmesg output from the 2.6.23-rc6 kernel with the patchset:

http://tglx.de/projects/hrtimers/2.6.23-rc4/patch-2.6.23-rc4-hrt1.patches.tar.bz2

applied.  I also have the 2.6.23-rc6-mm1 dmesg output ready, but there's some
-mm-specific noise in it.  Please let me know if you want it, though.

Greetings,
Rafael
Linux version 2.6.23-rc6-hrt ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #1 SMP Sat Sep 22 22:38:18 CEST 2007
Command line: root=/dev/sda3 vga=792 resume=/dev/sda1 noacpitimer apic=verbose 2
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000e - 0010 (reserved)
 BIOS-e820: 0010 - 77fd (usable)
 BIOS-e820: 77fd - 77fe5600 (reserved)
 BIOS-e820: 77fe5600 - 77ff8000 (ACPI NVS)
 BIOS-e820: 77ff8000 - 8000 (reserved)
 BIOS-e820: e000 - f000 (reserved)
 BIOS-e820: fec0 - fec02000 (reserved)
 BIOS-e820: ffbc - ffcc (reserved)
 BIOS-e820: fff0 - 0001 (reserved)
Entering add_active_range(0, 0, 159) 0 entries of 256 used
Entering add_active_range(0, 256, 491472) 1 entries of 256 used
end_pfn_map = 1048576
DMI 2.4 present.
ACPI: RSDP 000F7D30, 0024 (r2 HP)
ACPI: XSDT 77FE57B4, 0054 (r1 HP 0944  6070620 HP  1)
ACPI: FACP 77FE5684, 00F4 (r4 HP 09443 HP  1)
ACPI: DSDT 77FE58DC, EE7A (r1 HPSB4001 MSFT  10E)
ACPI: FACS 77FF7E80, 0040
ACPI: APIC 77FE5808, 0062 (r1 HP 09441 HP  1)
ACPI: MCFG 77FE586C, 003C (r1 HP 09441 HP  1)
ACPI: TCPA 77FE58A8, 0032 (r2 HP 09441 HP  1)
ACPI: SSDT 77FF4756, 0059 (r1 HP   HPQNLP1 MSFT  10E)
ACPI: SSDT 77FF47AF, 0206 (r1 HP PSSTBLID1 HP  1)
Entering add_active_range(0, 0, 159) 0 entries of 256 used
Entering add_active_range(0, 256, 491472) 1 entries of 256 used
No mptable found.
Zone PFN ranges:
  DMA 0 -> 4096
  DMA324096 ->  1048576
  Normal1048576 ->  1048576
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0:0 ->  159
0:  256 ->   491472
On node 0 totalpages: 491375
  DMA zone: 56 pages used for memmap
  DMA zone: 1446 pages reserved
  DMA zone: 2497 pages, LIFO batch:0
  DMA32 zone: 6663 pages used for memmap
  DMA32 zone: 480713 pages, LIFO batch:31
  Normal zone: 0 pages used for memmap
  Movable zone: 0 pages used for memmap
ATI board detected. Disabling timer routing over 8254.
ACPI: PM-Timer IO Port: 0x8008
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 21 low level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
mapped APIC to ff5fb000 (fee0)
mapped IOAPIC to ff5fa000 (fec0)
swsusp: Registered nosave memory region: 0009f000 - 000a
swsusp: Registered nosave memory region: 000a - 000e
swsusp: Registered nosave memory region: 000e - 0010
Allocating PCI resources starting at 8800 (gap: 8000:6000)
SMP: Allowing 2 CPUs, 0 hotplug CPUs
PERCPU: Allocating 47576 bytes of per cpu data
Built 1 zonelists in Zone order.  Total pages: 483210
Kernel command line: root=/dev/sda3 vga=792 resume=/dev/sda1 noacpitimer apic=verbose 2
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 

[PATCH v3] iw_cxgb3: Support "iwarp-only" interfaces to avoid 4-tuple conflicts.

[Steve Wise]

iw_cxgb3: Support "iwarp-only" interfaces to avoid 4-tuple conflicts.

Version 3:

- don't use list_del_init() where list_del() is sufficient.

Version 2:

- added a per-device mutex for the address and listening endpoints lists.

- wait for all replies if sending multiple passive_open requests to rnic.

- log warning if no addresses are available when a listen is issued.

- tested

---

Design:

The sysadmin creates "for iwarp use only" alias interfaces of the form
"devname:iw*" where devname is the native interface name (eg eth0) for the
iwarp netdev device.  The alias label can be anything starting with "iw".
The "iw" immediately after the ':' is the key used by the iw_cxgb3 driver.

EG:
ifconfig eth0 192.168.70.123 up
ifconfig eth0:iw1 192.168.71.123 up
ifconfig eth0:iw2 192.168.72.123 up

In the above example, 192.168.70/24 is for TCP traffic, while
192.168.71/24 and 192.168.72/24 are for iWARP/RDMA use.

The rdma-only interface must be on its own IP subnet. This allows routing
all rdma traffic onto this interface.

The iWARP driver must translate all listens on address 0.0.0.0 to the
set of rdma-only ip addresses for the device in question.  This prevents
incoming connect requests to the TCP ipaddresses from going up the
rdma stack.

Implementation Details:

- The iw_cxgb3 driver registers for inetaddr events via
register_inetaddr_notifier().  This allows tracking the iwarp-only
addresses/subnets as they get added and deleted.  The iwarp driver
maintains a list of the current iwarp-only addresses.

- The iw_cxgb3 driver builds the list of iwarp-only addresses for its
devices at module insert time.  This is needed because the inetaddr
notifier callbacks don't "replay" address-add events when someone
registers.  So the driver must build the initial list at module load time.

- When a listen is done on address 0.0.0.0, then the iw_cxgb3 driver
must translate that into a set of listens on the iwarp-only addresses.
This is implemented by maintaining a list of stid/addr entries per
listening endpoint.

- When a new iwarp-only address is added or removed, the iw_cxgb3 driver
must traverse the set of listening endpoints and update them accordingly.
This allows an application to bind to 0.0.0.0 prior to the iwarp-only
interfaces being configured.  It also allows changing the iwarp-only set
of addresses and getting the expected behavior for apps already bound
to 0.0.0.0.  This is done by maintaining a list of listening endpoints
off the device struct.

- The address list, the listening endpoint list, and each list of
stid/addrs in use per listening endpoint are all protected via a mutex
per iw_cxgb3 device.

Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---

 drivers/infiniband/hw/cxgb3/iwch.c|  125 
 drivers/infiniband/hw/cxgb3/iwch.h|   11 +
 drivers/infiniband/hw/cxgb3/iwch_cm.c |  259 +++--
 drivers/infiniband/hw/cxgb3/iwch_cm.h |   15 ++
 4 files changed, 360 insertions(+), 50 deletions(-)

diff --git a/drivers/infiniband/hw/cxgb3/iwch.c 
b/drivers/infiniband/hw/cxgb3/iwch.c
index 0315c9d..d81d46e 100644
--- a/drivers/infiniband/hw/cxgb3/iwch.c
+++ b/drivers/infiniband/hw/cxgb3/iwch.c
@@ -63,6 +63,123 @@ struct cxgb3_client t3c_client = {
 static LIST_HEAD(dev_list);
 static DEFINE_MUTEX(dev_mutex);
 
+static void insert_ifa(struct iwch_dev *rnicp, struct in_ifaddr *ifa)
+{
+   struct iwch_addrlist *addr;
+
+   addr = kmalloc(sizeof *addr, GFP_KERNEL);
+   if (!addr) {
+   printk(KERN_ERR MOD "%s - failed to alloc memory!\n",
+  __FUNCTION__);
+   return;
+   }
+   addr->ifa = ifa;
+   mutex_lock(>mutex);
+   list_add_tail(>entry, >addrlist);
+   mutex_unlock(>mutex);
+}
+
+static void remove_ifa(struct iwch_dev *rnicp, struct in_ifaddr *ifa)
+{
+   struct iwch_addrlist *addr, *tmp;
+
+   mutex_lock(>mutex);
+   list_for_each_entry_safe(addr, tmp, >addrlist, entry) {
+   if (addr->ifa == ifa) {
+   list_del(>entry);
+   kfree(addr);
+   goto out;
+   }
+   }
+out:
+   mutex_unlock(>mutex);
+}
+
+static int netdev_is_ours(struct iwch_dev *rnicp, struct net_device *netdev)
+{
+   int i;
+
+   for (i = 0; i < rnicp->rdev.port_info.nports; i++)
+   if (netdev == rnicp->rdev.port_info.lldevs[i])
+   return 1;
+   return 0;
+}
+
+static inline int is_iwarp_label(char *label)
+{
+   char *colon;
+
+   colon = strchr(label, ':');
+   if (colon && !strncmp(colon+1, "iw", 2))
+   return 1;
+   return 0;
+}
+
+static int nb_callback(struct notifier_block *self, unsigned long event,
+  void *ctx)
+{
+   struct in_ifaddr *ifa = ctx;
+   struct iwch_dev *rnicp = container_of(self, struct iwch_dev, nb);
+
+   PDBG("%s rnicp %p event %lx\n", __FUNCTION__, rnicp, 

Re: [PATCH][RFC] Extend "memparse" to allow a NULL return pointer value.

[Oleg Verych]

* Sat, 15 Sep 2007 12:27:07 -0400 (EDT)

> Extend the memparse() routine to allow a caller to use NULL as the
> second parameter value if he has no interest in that returned value.

(not `he', but `it', even if `he', then better `callers' + `they')

> ---
>
>   there appear to be quite a number of calls to "memparse" which have
> no use for the value returned in the second parameter (the current
> pointer after the successful parse), but which are still forced to
> supply a valid char** address since they have no choice but to accept
> that value coming back.  in many cases, that value is accepted just
> before the end of the calling function, making it clear that the value
> is ignored entirely, anyway.

A posteriori value, stored in this pointer serves very important role: it
validates returned result. Caller must do this. But if programmer doesn't
know problems (see below), `must' melts down to `may'.

If you take a look at simple_strtoull(), it already doesn't care if this
pointer is NULL or not. (So patch is NULL :)

But take closer look. If it returns `0' (zero), it is not clear if this
zero was parsed or not, unless you can compare `ptr' and `retptr'.
Another case if entire string have no valid number to parse (see
strtol(3)).

This is problem of this particular function, that is copied form
ordinary C. For instance see .
--
-o--=O`C
 #oo'L O
<___=E M
-
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: [ofa-general] [PATCH v2] iw_cxgb3: Support "iwarp-only" interfaces to avoid 4-tuple conflicts.

[Steve Wise]

Sean Hefty wrote:

The iWARP driver must translate all listens on address 0.0.0.0 to the
set of rdma-only ip addresses for the device in question.  This prevents
incoming connect requests to the TCP ipaddresses from going up the
rdma stack.


I've only given this a high level review at this point, and while the 
patch looks okay on first pass, is there a way to move some of this 
functionality to either the rdma_cm or iw_cm?  I don't like the idea of 
every iwarp driver having to implement address/listen list maintenance. 
 I may have some ideas after re-examining it.




Note: some rnic drivers might want to support this differently.  So 
maybe we don't want this in the iwcm yet until we see that more iwarp 
drivers need exactly the same functionality.




Implementation Details:


There are a couple of areas that I made a note to look at in more detail 
(because I didn't understand everything that was happening), but I did 
have one minor nit - most uses of list_del_init can just be list_del.




fixed.

-
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/7] Extended crashkernel command line

[Bernhard Walle]

* Oleg Verych <[EMAIL PROTECTED]> [2007-09-23 01:14]:
> * Thu, 20 Sep 2007 19:18:46 +0200
> 
> []
> >  extern u32 vmcoreinfo_note[VMCOREINFO_NOTE_SIZE/4];
> >  extern unsigned int vmcoreinfo_size;
> >  extern unsigned int vmcoreinfo_max_size;
> > +int __init parse_crashkernel(char *cmdline, unsigned long long system_ram,
> > +   unsigned long long *crash_size, unsigned long long *crash_base);
> 
> (BTW, why `system_ram' is `unsigned long' in parse_crashkernel_mem() but
> `unsigned long long' in parse_crashkernel()?)

Because that's a bug, thanks for spotting that out. I will sent an
updated version of this patch until the issue below has been
clarified:

> What is the point of not using `ulong' and `u64'?
> 
> What about another names?
> 
>  +int __init get_crashkernel_params(u64 *memsize, u64 *addrbase, char 
> *cmdline, u64 ram);

Andrew, what's your opinion on this? Whould I resend the patch with
shorter type names?


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

[PATCH3/4] [PPC] Compile fix for 8xx CPM Ehernet driver

[Jochen Friedrich]

Add #include  for flush_dcache_range
to make the driver compile again.

 CC  arch/ppc/8xx_io/enet.o
arch/ppc/8xx_io/enet.c: In function 'scc_enet_start_xmit':
arch/ppc/8xx_io/enet.c:240: error: implicit declaration of function
'flush_dcache_range'
make[1]: *** [arch/ppc/8xx_io/enet.o] Error 1
make: *** [arch/ppc/8xx_io] Error 2

Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
---
arch/ppc/8xx_io/enet.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/ppc/8xx_io/enet.c b/arch/ppc/8xx_io/enet.c
index 703d47e..eace3bc 100644
--- a/arch/ppc/8xx_io/enet.c
+++ b/arch/ppc/8xx_io/enet.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  *Theory of Operation

[PATCH4/4] [POWERPC] Fix cpm_uart driver

[Jochen Friedrich]

In cpm_uart_core, functions cpm_uart_init_bd and cpm_uart_init_scc
an offset into DP RAM is calculated by substracting a physical
memory constant from an virtual address. This patch fixes the
problem by converting the virtual address into a physical
first.

Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
---
drivers/serial/cpm_uart/cpm_uart_core.c |   12 
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
index cefde58..7f5db7c 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -752,8 +752,10 @@ static void cpm_uart_init_scc(struct uart_cpm_port *pinfo)
 	sup = pinfo->sccup;
 
 	/* Store address */
-	pinfo->sccup->scc_genscc.scc_rbase = (unsigned char *)pinfo->rx_bd_base - DPRAM_BASE;
-	pinfo->sccup->scc_genscc.scc_tbase = (unsigned char *)pinfo->tx_bd_base - DPRAM_BASE;
+	pinfo->sccup->scc_genscc.scc_rbase = 
+		(u_char *)cpm_dpram_phys((u8 *)pinfo->rx_bd_base) - DPRAM_BASE;
+	pinfo->sccup->scc_genscc.scc_tbase = 
+		(u_char *)cpm_dpram_phys((u8 *)pinfo->tx_bd_base) - DPRAM_BASE;
 
 	/* Set up the uart parameters in the
 	 * parameter ram.
@@ -813,8 +815,10 @@ static void cpm_uart_init_smc(struct uart_cpm_port *pinfo)
 	up = pinfo->smcup;
 
 	/* Store address */
-	pinfo->smcup->smc_rbase = (u_char *)pinfo->rx_bd_base - DPRAM_BASE;
-	pinfo->smcup->smc_tbase = (u_char *)pinfo->tx_bd_base - DPRAM_BASE;
+	pinfo->smcup->smc_rbase = 
+		(u_char *)cpm_dpram_phys((u8 *)pinfo->rx_bd_base) - DPRAM_BASE;
+	pinfo->smcup->smc_tbase = 
+		(u_char *)cpm_dpram_phys((u8 *)pinfo->tx_bd_base) - DPRAM_BASE;
 
 /*
  *  In case SMC1 is being relocated...

[PATCH2/4] [PPC] Fix cpm_dpram_addr returning phys mem instead of virt mem

[Jochen Friedrich]

cpm_dpram_addr returns physical memory of the DP RAM instead of
iomapped virtual memory. As there usually is a 1:1 MMU map of
the IMMR area, this is often not noticed. However, cpm_dpram_phys
assumes this iomapped virtual memory and returns garbage on the
1:1 mapped memory causing CPM1 uart console to fail.

This patch fixes the problem (copied from the powerpc tree).

Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
---
arch/ppc/8xx_io/commproc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/ppc/8xx_io/commproc.c b/arch/ppc/8xx_io/commproc.c
index 7088428..9da880b 100644
--- a/arch/ppc/8xx_io/commproc.c
+++ b/arch/ppc/8xx_io/commproc.c
@@ -459,7 +459,7 @@ EXPORT_SYMBOL(cpm_dpdump);
 
 void *cpm_dpram_addr(unsigned long offset)
 {
-	return ((immap_t *)IMAP_ADDR)->im_cpm.cp_dpmem + offset;
+	return (void *)(dpram_vbase + offset);
 }
 EXPORT_SYMBOL(cpm_dpram_addr);
 

[PATCH1/4] [POWERPC] Fix copy'n'paste typo in commproc.c

[Jochen Friedrich]

The powerpc version of commproc.c doesn't export cpm_dpram_addr twice
and cpm_dpram_phys not at all due to a typo. This patch fixes this
problem.

CC  arch/powerpc/sysdev/commproc.o
arch/powerpc/sysdev/commproc.c:398: error: redefinition of 
'__kcrctab_cpm_dpram_addr'
arch/powerpc/sysdev/commproc.c:392: error: previous definition of 
'__kcrctab_cpm_dpram_addr' was here
arch/powerpc/sysdev/commproc.c:398: error: redefinition of 
'__kstrtab_cpm_dpram_addr'
arch/powerpc/sysdev/commproc.c:392: error: previous definition of 
'__kstrtab_cpm_dpram_addr' was here
arch/powerpc/sysdev/commproc.c:398: error: redefinition of 
'__ksymtab_cpm_dpram_addr'
arch/powerpc/sysdev/commproc.c:392: error: previous definition of 
'__ksymtab_cpm_dpram_addr' was here
make[1]: *** [arch/powerpc/sysdev/commproc.o] Error 1
make: *** [arch/powerpc/sysdev] Error 2

Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/commproc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/commproc.c
index 4f67b89..dd5417a 100644
--- a/arch/powerpc/sysdev/commproc.c
+++ b/arch/powerpc/sysdev/commproc.c
@@ -395,4 +395,4 @@ uint cpm_dpram_phys(u8* addr)
 {
 	return (dpram_pbase + (uint)(addr - dpram_vbase));
 }
-EXPORT_SYMBOL(cpm_dpram_addr);
+EXPORT_SYMBOL(cpm_dpram_phys);

[PATCH0/4] Various bug fixes

[Jochen Friedrich]

Here is a series fixing some bugs for 8xx powerpc CPUs.

1. [POWERPC] Fix copy'n'paste typo in commproc.c
2. [PPC] Fix cpm_dpram_addr returning phys mem instead of virt mem
3. [PPC] Compile fix for 8xx CPM Ehernet driver
4. [POWERPC] Fix cpm_uart driver

This series can be pulled from git://git.bocc.de/dbox2.git ppc-fixes

Thanks,
Jochen

-
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] please pull infiniband.git

[Roland Dreier]

Linus, please pull from

master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus

This tree is also available from kernel.org mirrors at:

git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git 
for-linus

This will get one fix for a data corruption bug in 2.6.23-rc7:

Jack Morgenstein (1):
  IB/mlx4: Fix data corruption triggered by wrong headroom marking order

 drivers/infiniband/hw/mlx4/qp.c |   62 ++
 1 files changed, 49 insertions(+), 13 deletions(-)


diff --git a/drivers/infiniband/hw/mlx4/qp.c b/drivers/infiniband/hw/mlx4/qp.c
index ba0428d..85c51bd 100644
--- a/drivers/infiniband/hw/mlx4/qp.c
+++ b/drivers/infiniband/hw/mlx4/qp.c
@@ -1211,12 +1211,42 @@ static void set_datagram_seg(struct 
mlx4_wqe_datagram_seg *dseg,
dseg->qkey = cpu_to_be32(wr->wr.ud.remote_qkey);
 }
 
-static void set_data_seg(struct mlx4_wqe_data_seg *dseg,
-struct ib_sge *sg)
+static void set_mlx_icrc_seg(void *dseg)
+{
+   u32 *t = dseg;
+   struct mlx4_wqe_inline_seg *iseg = dseg;
+
+   t[1] = 0;
+
+   /*
+* Need a barrier here before writing the byte_count field to
+* make sure that all the data is visible before the
+* byte_count field is set.  Otherwise, if the segment begins
+* a new cacheline, the HCA prefetcher could grab the 64-byte
+* chunk and get a valid (!= * 0x) byte count but
+* stale data, and end up sending the wrong data.
+*/
+   wmb();
+
+   iseg->byte_count = cpu_to_be32((1 << 31) | 4);
+}
+
+static void set_data_seg(struct mlx4_wqe_data_seg *dseg, struct ib_sge *sg)
 {
-   dseg->byte_count = cpu_to_be32(sg->length);
dseg->lkey   = cpu_to_be32(sg->lkey);
dseg->addr   = cpu_to_be64(sg->addr);
+
+   /*
+* Need a barrier here before writing the byte_count field to
+* make sure that all the data is visible before the
+* byte_count field is set.  Otherwise, if the segment begins
+* a new cacheline, the HCA prefetcher could grab the 64-byte
+* chunk and get a valid (!= * 0x) byte count but
+* stale data, and end up sending the wrong data.
+*/
+   wmb();
+
+   dseg->byte_count = cpu_to_be32(sg->length);
 }
 
 int mlx4_ib_post_send(struct ib_qp *ibqp, struct ib_send_wr *wr,
@@ -1225,6 +1255,7 @@ int mlx4_ib_post_send(struct ib_qp *ibqp, struct 
ib_send_wr *wr,
struct mlx4_ib_qp *qp = to_mqp(ibqp);
void *wqe;
struct mlx4_wqe_ctrl_seg *ctrl;
+   struct mlx4_wqe_data_seg *dseg;
unsigned long flags;
int nreq;
int err = 0;
@@ -1324,22 +1355,27 @@ int mlx4_ib_post_send(struct ib_qp *ibqp, struct 
ib_send_wr *wr,
break;
}
 
-   for (i = 0; i < wr->num_sge; ++i) {
-   set_data_seg(wqe, wr->sg_list + i);
+   /*
+* Write data segments in reverse order, so as to
+* overwrite cacheline stamp last within each
+* cacheline.  This avoids issues with WQE
+* prefetching.
+*/
 
-   wqe  += sizeof (struct mlx4_wqe_data_seg);
-   size += sizeof (struct mlx4_wqe_data_seg) / 16;
-   }
+   dseg = wqe;
+   dseg += wr->num_sge - 1;
+   size += wr->num_sge * (sizeof (struct mlx4_wqe_data_seg) / 16);
 
/* Add one more inline data segment for ICRC for MLX sends */
-   if (qp->ibqp.qp_type == IB_QPT_SMI || qp->ibqp.qp_type == 
IB_QPT_GSI) {
-   ((struct mlx4_wqe_inline_seg *) wqe)->byte_count =
-   cpu_to_be32((1 << 31) | 4);
-   ((u32 *) wqe)[1] = 0;
-   wqe  += sizeof (struct mlx4_wqe_data_seg);
+   if (unlikely(qp->ibqp.qp_type == IB_QPT_SMI ||
+qp->ibqp.qp_type == IB_QPT_GSI)) {
+   set_mlx_icrc_seg(dseg + 1);
size += sizeof (struct mlx4_wqe_data_seg) / 16;
}
 
+   for (i = wr->num_sge - 1; i >= 0; --i, --dseg)
+   set_data_seg(dseg, wr->sg_list + i);
+
ctrl->fence_size = (wr->send_flags & IB_SEND_FENCE ?
MLX4_WQE_CTRL_FENCE : 0) | size;
 
-
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] New kernel-message logging API

[Rob Landley]

On Saturday 22 September 2007 2:27:29 pm Vegard Nossum wrote:
> After recent discussions on LKML and a general dissatisfaction at the
> current printk() kernel-message logging interface, I've decided to
> write down some of the ideas for a better system.
>
>
> Requirements
> 
>
>  * Backwards compatibility with printk(), syslog(), etc.

I.E. what we have now works just fine for what it does.

>  * Extensibility. Features like timestamping or file/line recording
> [1] should be both selectable at compile-time and (if compiled in) at
> run-time.

That doesn't require changing the API.  Allowing the compiler to eliminate 
messages below a threshold requires changing the API.

>
> API
> ===
>
> #define kprint(fmt, ...)
>
> The main part of the kprint interface should be the kprint() function.

And then you propose not having a single kprint() function...

> To support the different log-levels, there exists one kprint_*()
> function for each log-level, for example kprint_info().

Why is this better than feeding the level in as an argument to the macro?

> In order to print several related lines as one chunk, the emitter
> should first allocate an object of the type struct kprint_buffer.

You know, I'm pretty happy with a first pass that doesn't address this issue 
at all.  Why bundle three unrelated problems into a single all-or-nothing 
pass?

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

Re: 2.6.23-rc4-mm1 and -rc6-mm1: boot failure on HP nx6325, related to clockevents

[Thomas Gleixner]

On Sun, 2007-09-23 at 22:08 +0200, Rafael J. Wysocki wrote:
> > > Since the boot fails very early, before any messages reach the (VGA) 
> > > console,
> > > I have no idea what to do next, except for digging in the code.
> > 
> > Ok, lets track it down. Is there any difference when you add:
> > 
> > nohz=off
> > highres=off
> > noapictimer
> > 
> > or any combinations of the above to the kernel command line ?
> 
> First, for now, I build all kernels with NO_HZ and HIGH_RES_TIMERS unset
> (.config for 2.6.23-rc6-mm1 is attached).
> 
> Second, noacpitimer added to the command line makes all of the kernels, up to
> and including 2.6.23-rc6-mm1, boot (this seems to be 100% reproducible).

That's valuable information. Can you please provide a boot log of one of
those with an additional "apic=verbose" on the command line ?

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: Memory allocation problem with 2.6.22 after suspend/resume cycle

[Rafael J. Wysocki]

On Sunday, 23 September 2007 21:18, Christian P. Schmidt wrote:
> Rafael J. Wysocki wrote:
> > On Sunday, 23 September 2007 18:19, Christian P. Schmidt wrote:
> >> Rafael J. Wysocki wrote:
> >>> On Sunday, 23 September 2007 14:38, Christian P. Schmidt wrote:
>  Rafael J. Wysocki wrote:
> > On Saturday, 22 September 2007 17:41, Christian P. Schmidt wrote:
> >> Hi all,
> >>
> >> I'm having a strange problem, of course not reproducible. Sometimes
> >> after a suspend (to ram) and resume cycle, the kernel will try to free
> >> all memory. This means, all running applications are flushed to swap 
> >> (as
> >> long as it is available), caches and buffers stay at around 15MB each.
> >>
> >> The following video (traded quality for bandwidth) shows what happens 
> >> on
> >> the way from no swap to "swapon -a" (that's the unreadable thing in the
> >> small shell): http://digadd.de/swapping.avi
> >>
> >> The system:
> >> Linux dnnote 2.6.22.5 #1 SMP PREEMPT Sat Aug 25 18:39:21 AST 2007 
> >> x86_64
> >> Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz GenuineIntel GNU/Linux
> > Are you using an ATI binary graphics driver?
>  Yes. I do not (yet) have a choice... can't wait for the open source 
>  drivers.
> >>> That, most probably, is the source of the problem.  Please see:
> >>> http://bugzilla.kernel.org/show_bug.cgi?id=8943
> >> I do however not agree with Andrew's conclusion, as the memory is not
> >> "used", so I wouldn't expect a memory leak. As soon as I turn swapping
> >> off everything is loaded again, and works. If there was a leak it should
> >> use the memory, shouldn't it?
> >> If the problem would be 100% reproducible I could try without, but as
> >> is, I have up to two weeks with 2-3 cycles daily (sometimes more, as I
> >> receive untraceable SERR from my PCI-E WLAN after which I do not receive
> >> interrupts any more - only a suspend/resume cycle helps...) before the
> >> problem occurs.
> >>
> >> Anyway, is there a way of unloading the module temporarily without
> >> shutting X down?
> > 
> > I don't know.
> > 
> > Can you try another version of the ATI driver?  The reporter of this 
> > bugzilla
> > entry did that and it apparently helped him:
> > http://bugzilla.kernel.org/show_bug.cgi?id=8943#c4
> 
> That driver is even more broken, produces artifacts all over the place.
> I'll rather wait for the open source work to be done and live with the
> situation.
> 
> >> A 32bit Kernel is unable to suspend/resume at all. No idea why. dmesg
> >> shows nothing, logs show nothing. Any ideas for debugging are welcome.
> > Well, that's interesting.
> >
> > Can you try in the minimal configuration (ie. boot with init=/bin/bash,
> > mount /sys, mount /proc and run "echo mem > /sys/power/disk)?
>  Which? the 32bit or the 64bit?
> >>> 32-bit, but please do that without the ATI driver.
> >> Did it. As before, suspends, but when I resume, I hear the CD-ROM spin
> >> up, the backlight comes on, and nothing more. The system is a Lenovo
> >> Thinkpad T60 8744-4XG, BIOS 1.09.
> > 
> > Are you 100% sure that your 32-bit kernel configuration reflects the 64-bit
> > one?  In particular, do you have CONFIG_NO_HZ set in the 32-bit .config?
> 
> In both, not. 1000Hz timer, SMP support, hotplug CPU support are
> enabled. I attached a diff (from the 64bit to the 32bit). Maybe I'm
> missing something.

Yes.

Can you try to unset CONFIG_HIGH_RES_TIMERS in the 32-bit .config and retest,
please?

> > Also, would you be able to repeat this test with the latest -git kernel
> > (currently 2.6.23-rc7-git4)?
> 
> Not that I'd really care about the 32bit support, but someone else will.

Exactly.  Plus there are some things in the 32-bit kernel that are going to be
present in the 64-bit one in the future. ;-)

> Also, the 32bit version has problems with the SATA DVD-RW; it hangs for
> several seconds resetting the port (same kernel version, both 2.6.22.5),
> while the 64bit hasn't. Funny ;)
> Sadly, I know that 2.6.23 breaks/will break all the external modules I
> rely on. Anyway, I'll give it a shot later.

You can build it non-modular.

Greetings,
Rafael
-
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.23-rc4-mm1 and -rc6-mm1: boot failure on HP nx6325, related to clockevents

[Rafael J. Wysocki]

On Sunday, 23 September 2007 21:10, Thomas Gleixner wrote:
> On Sun, 2007-09-23 at 12:57 +0200, Rafael J. Wysocki wrote:
> > Hi Thomas,
> > 
> > Unfortunately, my observation that the patch series:
> > 
> > http://tglx.de/projects/hrtimers/2.6.23-rc4/patch-2.6.23-rc4-hrt1.patches.tar.bz2
> > 
> > worked with 2.6.23-rc4 was wrong.  It _sometimes_ works, but usually doesn't
> > boot, just like 2.6.23-rc4-mm1, 2.6.23-rc6-mm1 and everything in between 
> > with
> > the above patch series applied.  I've also tried:
> > 
> > http://tglx.de/projects/hrtimers/2.6.23-rc5/patch-2.6.23-rc5-hrt1.patches.tar.bz2
> > http://tglx.de/projects/hrtimers/2.6.23-rc6/patch-2.6.23-rc6-hrt2.patch
> > 
> > with the same result.
> > 
> > The problematic patch is x86_64-convert-to-clockevents.patch .
> > 
> > Since the boot fails very early, before any messages reach the (VGA) 
> > console,
> > I have no idea what to do next, except for digging in the code.
> 
> Ok, lets track it down. Is there any difference when you add:
> 
> nohz=off
> highres=off
> noapictimer
> 
> or any combinations of the above to the kernel command line ?

First, for now, I build all kernels with NO_HZ and HIGH_RES_TIMERS unset
(.config for 2.6.23-rc6-mm1 is attached).

Second, noacpitimer added to the command line makes all of the kernels, up to
and including 2.6.23-rc6-mm1, boot (this seems to be 100% reproducible).

Greetings,
Rafael
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.23-rc6-mm1
# Tue Sep 18 22:52:04 2007
#
CONFIG_X86_64=y
CONFIG_64BIT=y
CONFIG_X86=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_NONIRQ_WAKEUP=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_ZONE_DMA32=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_NR_QUICK=2
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_CMPXCHG=y
CONFIG_EARLY_PRINTK=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_DMI=y
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
# CONFIG_TASK_XACCT is not set
# CONFIG_USER_NS is not set
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_TREE=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=18
# CONFIG_CONTAINERS is not set
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_PROC_KPAGEMAP=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_BLK_DEV_BSG is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"

#
# Processor type and features
#
# CONFIG_TICK_ONESHOT is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_X86_PC=y
# CONFIG_X86_VSMP is not set
CONFIG_MK8=y
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_L1_CACHE_BYTES=64
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_INTERNODE_CACHE_BYTES=64
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_MTRR=y
CONFIG_SMP=y
# CONFIG_SCHED_SMT is not set
CONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_BKL=y
# CONFIG_NUMA is not set
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not 

Re: [PATCH 1/2 (v2)] cxacru: Use appropriate logging for errors

[Duncan Sands]

> - dbg("too big transfer requested");
> + if (printk_ratelimit())
> + usb_err(instance->usbatm, "requested transfer size too 
> large (%d, %d)\n",
> + wbuflen, rbuflen);

etc

Acked-by: Duncan Sands <[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: [RFC] New kernel-message logging API

[Joe Perches]

On Sun, 2007-09-23 at 10:45 +0200, Jan Engelhardt wrote:
> I'd rather fix up code to reduce its indent rather than
> trying microoptimizations at the function name level!

I think that's a different discussion.

You could fix some of them whenever you like.

$ egrep -r -l --include=*.c "^[[:cntrl:]]{6,}printk" *

cheers, Joe

-
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] New kernel-message logging API

[Joe Perches]

On Sun, 2007-09-23 at 10:39 +0200, Vegard Nossum wrote:
> On 9/23/07, Joe Perches <[EMAIL PROTECTED]> wrote:
> > Given the number of 80 column zealots, character naming length
> > matters.
> I don't know. Compare the following two lines:
> printk(KERN_INFO "Message.\n");
> kprint_info("Message.");

The problem isn't printk(KERN_ to kprint_(.

The problems are the no level printk(foo)s to kprint_(foo)
and the pr_() to kprint_() translations.

> By dropping the lengthy macro (it's not like it's going to change
> while we're running anyway, so why not make it a part of the function
> name?) and the final newline, we actually end up with a net decrease
> in line length.

Which I do appreciate and think good.

> I thought it would be nice to have something that looks familiar,
> since that would ease an eventual transition. klog is a valid
> alternative, but isn't kp a bit cryptic?

Probably no more than pr_ is today.

cheers, Joe

-
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.23-rc7 + radeonfb/s2ram

[Mihai Donțu]

On Sunday 23 September 2007, Rafael J. Wysocki wrote:
> On Sunday, 23 September 2007 20:31, Mihai Donțu wrote:
> > On Sunday 23 September 2007, Mihai Donțu wrote:
> > > I'll to do a full cleanup and start all over. I'm going to nail this 
> > > thing down if
> > > it's the last thing I do! (so help me God) :)
> > 
> >   Found it!
> > 
> >   The problem was "Framebuffer Console support". It was enabled by default 
> > in older
> >   configs (like 2.6.22.7) but I think someone noticed this was bad and put 
> > it to
> >   default N in newer (2.6.23-rc7); and since I reused the .config from 
> > 2.6.21.3 ...
> > 
> >   So there, if one wants "ATI Radeon display support" on Radeon XPRESS 200M 
> > with
> >   X using radeon_drv.so, *should* put "Framebuffer Console support" to N 
> > (if it's
> >   not already).
> > 
> >   Now all I have to do is figure out what's the equivalent of "vga=791" on 
> > the new
> >   kernel (default text console looks really bad on my laptop).
> > 
> >   Sorry for all the noise (and spam),
> 
> No, this actually is valuable information, thanks for it. :-)
> 
> [I have missed your first post, sorry for that.]

  Don't worry.

  Now, one last update (I've just ran into it): I was preparing my laptop (to 
brag
  tomorrow with my new s2ram thinggie) when I noticed that after powering up 
from a
  suspend-to-ram, X doesn't like radeonfb working behind it's back, as a result
  it goes crazy (corrupted pixmaps and such). I should have tested these two 
together :|

  Bottom line: no radeonfb for me :( at least, not now; but I have to be honest 
with
  you: I don't see what commit dd1447134454b169d5ae353aceb93f2368db8547 brought 
new
  into the picture. The previous radeonfb worked just great, but then, again, 
maybe I'm
  not using the console at it's full power :)

  I have attached the dmesg after power up.

  Thanks,

  (last post today, I swear to God!)

-- 
Mihai Donțu
[0.00] Linux version 2.6.23-rc7 ([EMAIL PROTECTED]) (gcc version 4.1.2 
(Gentoo 4.1.2)) #16 PREEMPT Sun Sep 23 21:45:39 EEST 2007
[0.00] Command line: nohz=on root=/dev/sda7 libata.noacpi=0
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 0009fc00 (usable)
[0.00]  BIOS-e820: 0009fc00 - 000a (reserved)
[0.00]  BIOS-e820: 000e - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - 37fd (usable)
[0.00]  BIOS-e820: 37fd - 37fefc00 (reserved)
[0.00]  BIOS-e820: 37fefc00 - 37ffb000 (ACPI NVS)
[0.00]  BIOS-e820: 37ffb000 - 4000 (reserved)
[0.00]  BIOS-e820: e000 - f000 (reserved)
[0.00]  BIOS-e820: fec0 - fec02000 (reserved)
[0.00]  BIOS-e820: ffb8 - ffc0 (reserved)
[0.00]  BIOS-e820: fff8 - 0001 (reserved)
[0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used
[0.00] Entering add_active_range(0, 256, 229328) 1 entries of 256 used
[0.00] end_pfn_map = 1048576
[0.00] DMI 2.3 present.
[0.00] ACPI: RSDP 000FE270, 0014 (r0 HP)
[0.00] ACPI: RSDT 37FEFC84, 0034 (r1 HP 0944 22110520 HP
  1)
[0.00] ACPI: FACP 37FEFC00, 0084 (r2 HP 09442 HP
  1)
[0.00] ACPI: DSDT 37FEFD50, 7489 (r1 HPSB4001 MSFT  
10E)
[0.00] ACPI: FACS 37FFAE80, 0040
[0.00] ACPI: APIC 37FEFCB8, 005A (r1 HP 09441 HP
  1)
[0.00] ACPI: MCFG 37FEFD14, 003C (r1 HP 09441 HP
  1)
[0.00] ACPI: SSDT 37FF71D9, 0382 (r1 HP   HPQPpc 1001 MSFT  
10E)
[0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used
[0.00] Entering add_active_range(0, 256, 229328) 1 entries of 256 used
[0.00] No mptable found.
[0.00] Zone PFN ranges:
[0.00]   DMA 0 -> 4096
[0.00]   DMA324096 ->  1048576
[0.00]   Normal1048576 ->  1048576
[0.00] Movable zone start PFN for each node
[0.00] early_node_map[2] active PFN ranges
[0.00] 0:0 ->  159
[0.00] 0:  256 ->   229328
[0.00] On node 0 totalpages: 229231
[0.00]   DMA zone: 56 pages used for memmap
[0.00]   DMA zone: 1911 pages reserved
[0.00]   DMA zone: 2032 pages, LIFO batch:0
[0.00]   DMA32 zone: 3079 pages used for memmap
[0.00]   DMA32 zone: 222153 pages, LIFO batch:31
[0.00]   Normal zone: 0 pages used for memmap
[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: 0x8008
[0.00] ACPI: Local APIC address 0xfec01000
[0.00] ACPI: LAPIC (acpi_id[0x01] 

Re: Memory allocation problem with 2.6.22 after suspend/resume cycle

[Christian P. Schmidt]

Rafael J. Wysocki wrote:
> On Sunday, 23 September 2007 18:19, Christian P. Schmidt wrote:
>> Rafael J. Wysocki wrote:
>>> On Sunday, 23 September 2007 14:38, Christian P. Schmidt wrote:
 Rafael J. Wysocki wrote:
> On Saturday, 22 September 2007 17:41, Christian P. Schmidt wrote:
>> Hi all,
>>
>> I'm having a strange problem, of course not reproducible. Sometimes
>> after a suspend (to ram) and resume cycle, the kernel will try to free
>> all memory. This means, all running applications are flushed to swap (as
>> long as it is available), caches and buffers stay at around 15MB each.
>>
>> The following video (traded quality for bandwidth) shows what happens on
>> the way from no swap to "swapon -a" (that's the unreadable thing in the
>> small shell): http://digadd.de/swapping.avi
>>
>> The system:
>> Linux dnnote 2.6.22.5 #1 SMP PREEMPT Sat Aug 25 18:39:21 AST 2007 x86_64
>> Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz GenuineIntel GNU/Linux
> Are you using an ATI binary graphics driver?
 Yes. I do not (yet) have a choice... can't wait for the open source 
 drivers.
>>> That, most probably, is the source of the problem.  Please see:
>>> http://bugzilla.kernel.org/show_bug.cgi?id=8943
>> I do however not agree with Andrew's conclusion, as the memory is not
>> "used", so I wouldn't expect a memory leak. As soon as I turn swapping
>> off everything is loaded again, and works. If there was a leak it should
>> use the memory, shouldn't it?
>> If the problem would be 100% reproducible I could try without, but as
>> is, I have up to two weeks with 2-3 cycles daily (sometimes more, as I
>> receive untraceable SERR from my PCI-E WLAN after which I do not receive
>> interrupts any more - only a suspend/resume cycle helps...) before the
>> problem occurs.
>>
>> Anyway, is there a way of unloading the module temporarily without
>> shutting X down?
> 
> I don't know.
> 
> Can you try another version of the ATI driver?  The reporter of this bugzilla
> entry did that and it apparently helped him:
> http://bugzilla.kernel.org/show_bug.cgi?id=8943#c4

That driver is even more broken, produces artifacts all over the place.
I'll rather wait for the open source work to be done and live with the
situation.

>> A 32bit Kernel is unable to suspend/resume at all. No idea why. dmesg
>> shows nothing, logs show nothing. Any ideas for debugging are welcome.
> Well, that's interesting.
>
> Can you try in the minimal configuration (ie. boot with init=/bin/bash,
> mount /sys, mount /proc and run "echo mem > /sys/power/disk)?
 Which? the 32bit or the 64bit?
>>> 32-bit, but please do that without the ATI driver.
>> Did it. As before, suspends, but when I resume, I hear the CD-ROM spin
>> up, the backlight comes on, and nothing more. The system is a Lenovo
>> Thinkpad T60 8744-4XG, BIOS 1.09.
> 
> Are you 100% sure that your 32-bit kernel configuration reflects the 64-bit
> one?  In particular, do you have CONFIG_NO_HZ set in the 32-bit .config?

In both, not. 1000Hz timer, SMP support, hotplug CPU support are
enabled. I attached a diff (from the 64bit to the 32bit). Maybe I'm
missing something.

> Also, would you be able to repeat this test with the latest -git kernel
> (currently 2.6.23-rc7-git4)?

Not that I'd really care about the 32bit support, but someone else will.
Also, the 32bit version has problems with the SATA DVD-RW; it hangs for
several seconds resetting the port (same kernel version, both 2.6.22.5),
while the 64bit hasn't. Funny ;)
Sadly, I know that 2.6.23 breaks/will break all the external modules I
rely on. Anyway, I'll give it a shot later.

Regards,
Chris

> Greetings,
> Rafael

--- /boot/config-2.6.22.5   2007-08-25 18:39:30.0 +0300
+++ config-2.6.22.5 2007-09-23 16:34:33.0 +0300
@@ -1,33 +1,26 @@
 #
 # Automatically generated make config: don't edit
 # Linux kernel version: 2.6.22.5
-# Sat Aug 25 18:35:55 2007
+# Mon Sep  3 15:45:00 2007
 #
-CONFIG_X86_64=y
-CONFIG_64BIT=y
-CONFIG_X86=y
+CONFIG_X86_32=y
 CONFIG_GENERIC_TIME=y
-CONFIG_GENERIC_TIME_VSYSCALL=y
-CONFIG_ZONE_DMA32=y
+CONFIG_CLOCKSOURCE_WATCHDOG=y
+CONFIG_GENERIC_CLOCKEVENTS=y
+CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
 CONFIG_LOCKDEP_SUPPORT=y
 CONFIG_STACKTRACE_SUPPORT=y
 CONFIG_SEMAPHORE_SLEEPERS=y
+CONFIG_X86=y
 CONFIG_MMU=y
 CONFIG_ZONE_DMA=y
-CONFIG_RWSEM_GENERIC_SPINLOCK=y
-CONFIG_GENERIC_HWEIGHT=y
-CONFIG_GENERIC_CALIBRATE_DELAY=y
-CONFIG_X86_CMPXCHG=y
-CONFIG_EARLY_PRINTK=y
+CONFIG_QUICKLIST=y
 CONFIG_GENERIC_ISA_DMA=y
 CONFIG_GENERIC_IOMAP=y
+CONFIG_GENERIC_BUG=y
+CONFIG_GENERIC_HWEIGHT=y
 CONFIG_ARCH_MAY_HAVE_PC_FDC=y
-CONFIG_ARCH_POPULATES_NODE_MAP=y
 CONFIG_DMI=y
-CONFIG_AUDIT_ARCH=y
-CONFIG_GENERIC_BUG=y
-# CONFIG_ARCH_HAS_ILOG2_U32 is not set
-# CONFIG_ARCH_HAS_ILOG2_U64 is not set
 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
 
 #
@@ -102,7 +95,9 @@
 # Block layer
 #
 CONFIG_BLOCK=y
+# CONFIG_LBD is not set
 

Re: 2.6.23-rc4-mm1 and -rc6-mm1: boot failure on HP nx6325, related to clockevents

[Thomas Gleixner]

On Sun, 2007-09-23 at 12:57 +0200, Rafael J. Wysocki wrote:
> Hi Thomas,
> 
> Unfortunately, my observation that the patch series:
> 
> http://tglx.de/projects/hrtimers/2.6.23-rc4/patch-2.6.23-rc4-hrt1.patches.tar.bz2
> 
> worked with 2.6.23-rc4 was wrong.  It _sometimes_ works, but usually doesn't
> boot, just like 2.6.23-rc4-mm1, 2.6.23-rc6-mm1 and everything in between with
> the above patch series applied.  I've also tried:
> 
> http://tglx.de/projects/hrtimers/2.6.23-rc5/patch-2.6.23-rc5-hrt1.patches.tar.bz2
> http://tglx.de/projects/hrtimers/2.6.23-rc6/patch-2.6.23-rc6-hrt2.patch
> 
> with the same result.
> 
> The problematic patch is x86_64-convert-to-clockevents.patch .
> 
> Since the boot fails very early, before any messages reach the (VGA) console,
> I have no idea what to do next, except for digging in the code.

Ok, lets track it down. Is there any difference when you add:

nohz=off
highres=off
noapictimer

or any combinations of the above to the kernel command line ?

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: 2.6.23-rc7 + radeonfb/s2ram

[Rafael J. Wysocki]

On Sunday, 23 September 2007 20:31, Mihai Donțu wrote:
> On Sunday 23 September 2007, Mihai Donțu wrote:
> > I'll to do a full cleanup and start all over. I'm going to nail this thing 
> > down if
> > it's the last thing I do! (so help me God) :)
> 
>   Found it!
> 
>   The problem was "Framebuffer Console support". It was enabled by default in 
> older
>   configs (like 2.6.22.7) but I think someone noticed this was bad and put it 
> to
>   default N in newer (2.6.23-rc7); and since I reused the .config from 
> 2.6.21.3 ...
> 
>   So there, if one wants "ATI Radeon display support" on Radeon XPRESS 200M 
> with
>   X using radeon_drv.so, *should* put "Framebuffer Console support" to N (if 
> it's
>   not already).
> 
>   Now all I have to do is figure out what's the equivalent of "vga=791" on 
> the new
>   kernel (default text console looks really bad on my laptop).
> 
>   Sorry for all the noise (and spam),

No, this actually is valuable information, thanks for it. :-)

[I have missed your first post, sorry for that.]

Greetings,
Rafael
-
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: A revised timerfd API

[Michael Kerrisk]

Davide Libenzi wrote:

On Sun, 23 Sep 2007, Davide Libenzi wrote:


On Sun, 23 Sep 2007, Michael Kerrisk wrote:


I applied this patch against 2.6.27-rc7, and wired up the syscalls as shown
in the definitions below.  When I ran the the program below, my system
immediately froze.  Can you try it on your system please.
There's an hrtimer_init() missing in timerfd_create(). I'll refactor the 
patch.


There's the case of a timerfd_gettime return status when the timerfd has 
not been set yet (ie, soon after a timerfd_create), to handle.

Current way is to return an (itimerspec) { 0, 0 }. Ok?


Seems reasonable.  In the analogous situation, the POSIX timers API 
returns a structure containing all zeros, at least on Linux.

-
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: memset as memzero

[Willy Tarreau]

On Sun, Sep 23, 2007 at 10:05:05AM -0700, Linus Torvalds wrote:
> 
> 
> On Sun, 23 Sep 2007, Arnaldo Carvalho de Melo wrote:
> > 
> > bzero! That is it, its nothing new, just a sane name to something [..]
> 
> No, please no!
> 
> The BSD memory functions are nasty. If you do bzero, you logically should 
> do the others too, and they are way inferior to the standard ones. Let's 
> not go there.
> 
> Besides, if we want to avoid mistakes, I would suggest going to a much 
> higher level. Ie more along the lines of also fixing the size and 
> alignment, and using something like
> 
>   #define memclear(p) memset(p, 0, sizeof(*(p)))

I don't like it when macros magically do sizeof(*p), because people often
think that the macro is smarter than it really is, and you commonly end
up with code looking like this :

 char *p;
 ...
 p = kmalloc(n);
 ...
 memclear(p);

This can happen for instance when replacing a stack-allocated buffer
with a malloc because it became too big for the stack. Such a mistake
is *very hard* to detect by human eye, while having "sizeof(*p)" in
the same function as "char *p" will trigger some automatisms in most
readers' brains.

> because if you actually do something like
> 
>   git grep 'memset.*,[]*0[]*,'
> 
> (those [..] things contatain a space and a tab), you'll see that a *lot* 
> of them share that pattern. 

At least current code is still greppable for such usages. Doing too
much magics with macros often harms debugging. I could agree with
having a macro to force the pattern to '0', but not to force the size.

> Not that I think it's really worth it.

I don't think either.

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/

[PATCH 1/2 (v2)] cxacru: Use appropriate logging for errors

[Simon Arlott]

When an error occurs, existing logging uses dbg() so the cause of a 
problem is hard to determine. Error conditions shouldn't only be 
properly reported with debugging enabled.

A side effect of this change is that when an uninitialised device 
is started, a log message similar to the following is sent:
cxacru 5-2:1.0: receive of cm 0x90 failed (-104)
This is normal - the device did not respond so firmware will be 
loaded.

Signed-Off-By: Simon Arlott <[EMAIL PROTECTED]>
---
On 23/09/07 17:17, Duncan Sands wrote:
> Hi Simon, don't these error messages (except the first) risk spamming
> the log if something goes wrong (like the modem being unplugged)?  How
> about rate-limiting them, like usbatm does?
> 
> Ciao,
> 
> Duncan.

Ok.

 drivers/usb/atm/cxacru.c |   43 ---
 1 files changed, 28 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/atm/cxacru.c b/drivers/usb/atm/cxacru.c
index 1e5ee88..50249a5 100644
--- a/drivers/usb/atm/cxacru.c
+++ b/drivers/usb/atm/cxacru.c
@@ -482,7 +482,9 @@ static int cxacru_cm(struct cxacru_data *instance, enum 
cxacru_cm_request cm,
int rbuflen = ((rsize - 1) / stride + 1) * CMD_PACKET_SIZE;
 
if (wbuflen > PAGE_SIZE || rbuflen > PAGE_SIZE) {
-   dbg("too big transfer requested");
+   if (printk_ratelimit())
+   usb_err(instance->usbatm, "requested transfer size too 
large (%d, %d)\n",
+   wbuflen, rbuflen);
ret = -ENOMEM;
goto fail;
}
@@ -493,8 +495,9 @@ static int cxacru_cm(struct cxacru_data *instance, enum 
cxacru_cm_request cm,
init_completion(>rcv_done);
ret = usb_submit_urb(instance->rcv_urb, GFP_KERNEL);
if (ret < 0) {
-   dbg("submitting read urb for cm %#x failed", cm);
-   ret = ret;
+   if (printk_ratelimit())
+   usb_err(instance->usbatm, "submit of read urb for cm 
%#x failed (%d)\n",
+   cm, ret);
goto fail;
}
 
@@ -510,27 +513,29 @@ static int cxacru_cm(struct cxacru_data *instance, enum 
cxacru_cm_request cm,
init_completion(>snd_done);
ret = usb_submit_urb(instance->snd_urb, GFP_KERNEL);
if (ret < 0) {
-   dbg("submitting write urb for cm %#x failed", cm);
-   ret = ret;
+   if (printk_ratelimit())
+   usb_err(instance->usbatm, "submit of write urb for cm 
%#x failed (%d)\n",
+   cm, ret);
goto fail;
}
 
ret = cxacru_start_wait_urb(instance->snd_urb, >snd_done, 
NULL);
if (ret < 0) {
-   dbg("sending cm %#x failed", cm);
-   ret = ret;
+   if (printk_ratelimit())
+   usb_err(instance->usbatm, "send of cm %#x failed 
(%d)\n", cm, ret);
goto fail;
}
 
ret = cxacru_start_wait_urb(instance->rcv_urb, >rcv_done, 
);
if (ret < 0) {
-   dbg("receiving cm %#x failed", cm);
-   ret = ret;
+   if (printk_ratelimit())
+   usb_err(instance->usbatm, "receive of cm %#x failed 
(%d)\n", cm, ret);
goto fail;
}
if (actlen % CMD_PACKET_SIZE || !actlen) {
-   dbg("response is not a positive multiple of %d: %#x",
-   CMD_PACKET_SIZE, actlen);
+   if (printk_ratelimit())
+   usb_err(instance->usbatm, "invalid response length to 
cm %#x: %d\n",
+   cm, actlen);
ret = -EIO;
goto fail;
}
@@ -538,12 +543,16 @@ static int cxacru_cm(struct cxacru_data *instance, enum 
cxacru_cm_request cm,
/* check the return status and copy the data to the output buffer, if 
needed */
for (offb = offd = 0; offd < rsize && offb < actlen; offb += 
CMD_PACKET_SIZE) {
if (rbuf[offb] != cm) {
-   dbg("wrong cm %#x in response", rbuf[offb]);
+   if (printk_ratelimit())
+   usb_err(instance->usbatm, "wrong cm %#x in 
response to cm %#x\n",
+   rbuf[offb], cm);
ret = -EIO;
goto fail;
}
if (rbuf[offb + 1] != CM_STATUS_SUCCESS) {
-   dbg("response failed: %#x", rbuf[offb + 1]);
+   if (printk_ratelimit())
+   usb_err(instance->usbatm, "response to cm %#x 
failed: %#x\n",
+   cm, rbuf[offb + 1]);
ret = -EIO;
goto fail;
}
@@ -582,14 +591,18 @@ static int cxacru_cm_get_array(struct cxacru_data 
*instance, enum cxacru_cm_requ
for (offb = 0; offb < len; ) {
   

Re: RFC: A revised timerfd API

[Davide Libenzi]

On Sun, 23 Sep 2007, Davide Libenzi wrote:

> On Sun, 23 Sep 2007, Michael Kerrisk wrote:
> 
> > I applied this patch against 2.6.27-rc7, and wired up the syscalls as shown
> > in the definitions below.  When I ran the the program below, my system
> > immediately froze.  Can you try it on your system please.
> 
> There's an hrtimer_init() missing in timerfd_create(). I'll refactor the 
> patch.

There's the case of a timerfd_gettime return status when the timerfd has 
not been set yet (ie, soon after a timerfd_create), to handle.
Current way is to return an (itimerspec) { 0, 0 }. Ok?



- Davide


-
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 3/3] cxacru: Cleanup code by removing "ret = ret;" assignments

[Simon Arlott]

On 23/09/07 17:20, Duncan Sands wrote:
> On Sunday 23 September 2007 17:36:08 Simon Arlott wrote:
>> Cleanup code by removing "ret = ret;" assignments.
>> 
>> Signed-Off-By: Simon Arlott <[EMAIL PROTECTED]>
> 
> Acked-by: Duncan Sands <[EMAIL PROTECTED]>

Nacked-by: Simon Arlott <[EMAIL PROTECTED]>

I'm only going to create a merge conflict with myself with this :|
It'll be included with 1/3 shortly.

-- 
Simon Arlott
-
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: A revised timerfd API

[Davide Libenzi]

On Sun, 23 Sep 2007, Michael Kerrisk wrote:

> I applied this patch against 2.6.27-rc7, and wired up the syscalls as shown
> in the definitions below.  When I ran the the program below, my system
> immediately froze.  Can you try it on your system please.

There's an hrtimer_init() missing in timerfd_create(). I'll refactor the 
patch.



- Davide


-
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: Urgent bugzilla mainteinance needed

[Natalie Protasevich]

On 9/23/07, David Woodhouse <[EMAIL PROTECTED]> wrote:
>
> On Sun, 2007-09-23 at 11:08 -0700, Natalie Protasevich wrote:
> > On 9/23/07, Diego Calleja <[EMAIL PROTECTED]> wrote:
> > > Take a look at http://bugzilla.kernel.org/show_bug.cgi?id=3710
> > >
> > > bugzilla tries to send a mail to the reporter, it fails ("unknown user 
> > > account"),
> > > but the error failure is appended as a bugzilla comment. Then bugzilla 
> > > tries to
> > > send that comment to everyone involved in the bug, including the reporter,
> > > so it fails again.Houston, we've a endless loop.
> > >
> > > There're 540 comments in that bug report already, and the bugme-daemon
> > > mail list is being spammed
> >
> > I just sent emails to those who maintain bugzilla software and systems
> > that run it, hope someone will be online soon to help alleviate
> > this...
>
> Bugzilla really shouldn't be accepting any mail with empty reverse-path
> (MAIL FROM:<>)

Ah, then should be easy fix then. I don't have access to the system
though, will have to helplessly wait until one of the guys picks up...
:(
Thanks...
>
> --
> dwmw2
>
>
-
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 2/3] cxacru: Reduce initialisation delay

[Simon Arlott]

On 23/09/07 17:23, Duncan Sands wrote:
> Hi Simon,
> 
>> +usb_info(usbatm, "started firmware\n");
> ...
>> +usb_info(usbatm, "loaded config data\n");
> 
> maybe these should be debug messages.  When are they useful?

They are probably only useful as debug messages - although it 
may be desirable to know when the configuration has been set.



Also... it doesn't make sense to load the configuration only 
in heavy_init - if the configuration is changed then there's 
no way in the module to resend it without powering the device 
down and up. Some sysfs parameters to change configuration 
could be useful... except there's no information as to what 
these settings are.

-- 
Simon Arlott
-
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: Urgent bugzilla mainteinance needed

[David Woodhouse]

On Sun, 2007-09-23 at 11:08 -0700, Natalie Protasevich wrote:
> On 9/23/07, Diego Calleja <[EMAIL PROTECTED]> wrote:
> > Take a look at http://bugzilla.kernel.org/show_bug.cgi?id=3710
> >
> > bugzilla tries to send a mail to the reporter, it fails ("unknown user 
> > account"),
> > but the error failure is appended as a bugzilla comment. Then bugzilla 
> > tries to
> > send that comment to everyone involved in the bug, including the reporter,
> > so it fails again.Houston, we've a endless loop.
> >
> > There're 540 comments in that bug report already, and the bugme-daemon
> > mail list is being spammed
> 
> I just sent emails to those who maintain bugzilla software and systems
> that run it, hope someone will be online soon to help alleviate
> this...

Bugzilla really shouldn't be accepting any mail with empty reverse-path
(MAIL FROM:<>)

-- 
dwmw2

-
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.23-rc7 + radeonfb/s2ram

[Mihai Donțu]

On Sunday 23 September 2007, Mihai Donțu wrote:
> I'll to do a full cleanup and start all over. I'm going to nail this thing 
> down if
> it's the last thing I do! (so help me God) :)

  Found it!

  The problem was "Framebuffer Console support". It was enabled by default in 
older
  configs (like 2.6.22.7) but I think someone noticed this was bad and put it to
  default N in newer (2.6.23-rc7); and since I reused the .config from 2.6.21.3 
...

  So there, if one wants "ATI Radeon display support" on Radeon XPRESS 200M with
  X using radeon_drv.so, *should* put "Framebuffer Console support" to N (if 
it's
  not already).

  Now all I have to do is figure out what's the equivalent of "vga=791" on the 
new
  kernel (default text console looks really bad on my laptop).

  Sorry for all the noise (and spam),

-- 
Mihai Donțu
-
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: Memory allocation problem with 2.6.22 after suspend/resume cycle

[Rafael J. Wysocki]

On Sunday, 23 September 2007 18:19, Christian P. Schmidt wrote:
> Rafael J. Wysocki wrote:
> > On Sunday, 23 September 2007 14:38, Christian P. Schmidt wrote:
> >> Rafael J. Wysocki wrote:
> >>> On Saturday, 22 September 2007 17:41, Christian P. Schmidt wrote:
>  Hi all,
> 
>  I'm having a strange problem, of course not reproducible. Sometimes
>  after a suspend (to ram) and resume cycle, the kernel will try to free
>  all memory. This means, all running applications are flushed to swap (as
>  long as it is available), caches and buffers stay at around 15MB each.
> 
>  The following video (traded quality for bandwidth) shows what happens on
>  the way from no swap to "swapon -a" (that's the unreadable thing in the
>  small shell): http://digadd.de/swapping.avi
> 
>  The system:
>  Linux dnnote 2.6.22.5 #1 SMP PREEMPT Sat Aug 25 18:39:21 AST 2007 x86_64
>  Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz GenuineIntel GNU/Linux
> >>> Are you using an ATI binary graphics driver?
> >> Yes. I do not (yet) have a choice... can't wait for the open source 
> >> drivers.
> > 
> > That, most probably, is the source of the problem.  Please see:
> > http://bugzilla.kernel.org/show_bug.cgi?id=8943
> 
> I do however not agree with Andrew's conclusion, as the memory is not
> "used", so I wouldn't expect a memory leak. As soon as I turn swapping
> off everything is loaded again, and works. If there was a leak it should
> use the memory, shouldn't it?
> If the problem would be 100% reproducible I could try without, but as
> is, I have up to two weeks with 2-3 cycles daily (sometimes more, as I
> receive untraceable SERR from my PCI-E WLAN after which I do not receive
> interrupts any more - only a suspend/resume cycle helps...) before the
> problem occurs.
> 
> Anyway, is there a way of unloading the module temporarily without
> shutting X down?

I don't know.

Can you try another version of the ATI driver?  The reporter of this bugzilla
entry did that and it apparently helped him:
http://bugzilla.kernel.org/show_bug.cgi?id=8943#c4

>  A 32bit Kernel is unable to suspend/resume at all. No idea why. dmesg
>  shows nothing, logs show nothing. Any ideas for debugging are welcome.
> >>> Well, that's interesting.
> >>>
> >>> Can you try in the minimal configuration (ie. boot with init=/bin/bash,
> >>> mount /sys, mount /proc and run "echo mem > /sys/power/disk)?
> >> Which? the 32bit or the 64bit?
> > 
> > 32-bit, but please do that without the ATI driver.
> 
> Did it. As before, suspends, but when I resume, I hear the CD-ROM spin
> up, the backlight comes on, and nothing more. The system is a Lenovo
> Thinkpad T60 8744-4XG, BIOS 1.09.

Are you 100% sure that your 32-bit kernel configuration reflects the 64-bit
one?  In particular, do you have CONFIG_NO_HZ set in the 32-bit .config?

Also, would you be able to repeat this test with the latest -git kernel
(currently 2.6.23-rc7-git4)?

Greetings,
Rafael
-
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: Urgent bugzilla mainteinance needed

[Natalie Protasevich]

On 9/23/07, Diego Calleja <[EMAIL PROTECTED]> wrote:
> Take a look at http://bugzilla.kernel.org/show_bug.cgi?id=3710
>
> bugzilla tries to send a mail to the reporter, it fails ("unknown user 
> account"),
> but the error failure is appended as a bugzilla comment. Then bugzilla tries 
> to
> send that comment to everyone involved in the bug, including the reporter,
> so it fails again.Houston, we've a endless loop.
>
> There're 540 comments in that bug report already, and the bugme-daemon
> mail list is being spammed

I just sent emails to those who maintain bugzilla software and systems
that run it, hope someone will be online soon to help alleviate
this...
> -
> 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/

Urgent bugzilla mainteinance needed

[Diego Calleja]

Take a look at http://bugzilla.kernel.org/show_bug.cgi?id=3710

bugzilla tries to send a mail to the reporter, it fails ("unknown user 
account"),
but the error failure is appended as a bugzilla comment. Then bugzilla tries to
send that comment to everyone involved in the bug, including the reporter,
so it fails again.Houston, we've a endless loop.

There're 540 comments in that bug report already, and the bugme-daemon
mail list is being spammed
-
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.23-rc7 + radeonfb/s2ram

[Mihai Donțu]

On Sunday 23 September 2007, Mihai Donțu wrote:
> On Sunday 23 September 2007, Benjamin Herrenschmidt wrote:
> > Heh, yup.
> > 
> > There have been some radeonfb patches around -rc6 or so. Can you try
> > backing them out and letting us know if that helps a) ?
> > 
> > In that case, Linus, we probably want to revert them...
> > 
> > Though looking at your PCI ID (5955), I don't think the patches should
> > have changed anything.
> 
> After four hours of bisecting, I got this, which dates back to 2.6.21, but
> I've been on 2.6.21.3 for too long and thus missed the commit (I just decided
> to be a good citizen and test things before they get out).
> 
> dd1447134454b169d5ae353aceb93f2368db8547 is first bad commit
> commit dd1447134454b169d5ae353aceb93f2368db8547
> Author: johan henriksson <[EMAIL PROTECTED]>
> Date:   Tue May 8 00:37:59 2007 -0700
> 
> radeonfb: Add support for Radeon xpress 200m
> 
> Added support for radeon xpress 200m(rs480).  Note that the card doesn't
> like dynclk turned on.
> 
> Signed-off-by: Johan Henriksson <[EMAIL PROTECTED]>
> Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> Cc: "Antonino A. Daplas" <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
> 
> :04 04 e553664a656ee329152789818b5b071a36ac1e45 
> 0a698ad7daa8cdfd9eb5304812845306c9feb2f9 M  drivers
> 
> I turned dynclk off, no result (although dynclk is preferred).
> 
> What is interesting, is that the driver ignores "vga=normal" and "jumps" to
> a quite high res (I think is 1024x768 or something; the fonts look really nice
> though :)).

  Something strange is going on here: after I cleaned up the bisect kernels,
  I booted 2.6.23-rc7 using something like:
  "vga=normal nohz=on root=/dev/sda7 libata.noacpi=0 pci=assing-busses"
  and explicitly selecting "Enable Video Mode Handling Helpers" (which normally
  gets automatically selected once I choose "ATI Radeon display support" but I
  - suffering from intense paranoia - selected it by hand prior to selecting ATI
  Radeon ...).

  I works! X is no longer acting weird. I can't use "vga=791" anymore (the 
screen
  goes blank until X loads => timings definitely changed) but it *works* and I 
don't
  know why _and_ I can't seem to be able to make it go back to being bad :)
  
  I did a diff between the .config used in bisect and the current .config. I 
don't
  see anything suspicious.

  I'll to do a full cleanup and start all over. I'm going to nail this thing 
down if
  it's the last thing I do! (so help me God) :)

-- 
Mihai Donțu
-
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: [00/41] Large Blocksize Support V7 (adds memmap support)

[Jörn Engel]

On Sun, 16 September 2007 11:44:09 -0700, Linus Torvalds wrote:
> On Sun, 16 Sep 2007, Jörn Engel wrote:
> > 
> > My approach is to have one for mount points and ramfs/tmpfs/sysfs/etc.
> > which are pinned for their entire lifetime and another for regular
> > files/inodes.  One could take a three-way approach and have
> > always-pinned, often-pinned and rarely-pinned.
> > 
> > We won't get never-pinned that way.
> 
> That sounds pretty good. The problem, of course, is that most of the time, 
> the actual dentry allocation itself is done before you really know which 
> case the dentry will be in, and the natural place for actually giving the 
> dentry lifetime hint is *not* at "d_alloc()", but when we "instantiate" 
> it with d_add() or d_instantiate().
> 
> [...]
> 
> And yes, you'd end up with the reallocation overhead quite often, but at 
> least it would now happen only when filling in a dentry, not in the 
> (*much* more critical) cached lookup path.

There may be another approach.  We could create a never-pinned cache,
without trying hard to keep it full.  Instead of moving a hot dentry at
dput() time, we move a cold one from the end of lru.  And if the lru
list is short, we just chicken out.

Our definition of "short lru list" can either be based on a ratio of
pinned to unpinned dentries or on a metric of cache hits vs. cache
misses.  I tend to dislike the cache hit metric, because updatedb would
cause tons of misses and result in the same mess we have right now.

With this double cache, we have a source of slabs to cheaply reap under
memory pressure, but still have a performance advantage (memcpy beats
disk io by orders of magnitude).

Jörn

-- 
The story so far:
In the beginning the Universe was created.  This has made a lot
of people very angry and been widely regarded as a bad move.
-- Douglas Adams
-
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: A revised timerfd API

[Michael Kerrisk]

Hi Davide,

Davide Libenzi wrote:
> On Sat, 22 Sep 2007, Michael Kerrisk wrote:
> 
>> So I'm inclined to implement option (b), unless someone has strong
>> objections.  Davide, could I persuade you to help?
> 
> I guess I better do, otherwise you'll continue to stress me ;)

Thanks -- that was more than I hoped for!

> int timerfd_create(int clockid);
> int timerfd_settime(int ufd, int flags,
> const struct itimerspec *utmr,
> struct itimerspec *otmr);
> int timerfd_gettime(int ufd, struct itimerspec *otmr);
> 
> Patch below. Builds, not tested yet (you need to remove the "broken" 
> status from CONFIG_TIMERFD in case you want to test - and plug the new 
> syscall to arch/xxx).

I applied this patch against 2.6.27-rc7, and wired up the syscalls as shown
in the definitions below.  When I ran the the program below, my system
immediately froze.  Can you try it on your system please.

Cheers,

Michael

/* Link with -lrt */

#define _GNU_SOURCE
#include 
#include 
#include 
#if defined(__i386__)
#define __NR_timerfd_create 325
#define __NR_timerfd_settime 326
#define __NR_timerfd_gettime 327
17170:man-pages/man2> cat timerfd3_test.c
/* Link with -lrt */

#define _GNU_SOURCE
#include 
#include 
#include 
#if defined(__i386__)
#define __NR_timerfd_create 325
#define __NR_timerfd_settime 326
#define __NR_timerfd_gettime 327
#endif

static int
timerfd_create(int clockid)
{
return syscall(__NR_timerfd_create, clockid);
}

static int
timerfd_settime(int ufd, int flags, struct itimerspec *utmr,
struct itimerspec *outmr)
{
return syscall(__NR_timerfd_settime, ufd, flags, utmr, outmr);
}

static int
timerfd_gettime(int ufd, struct itimerspec *outmr)
{
return syscall(__NR_timerfd_gettime, ufd, outmr);
}

/*
static int
timerfd(int ufd, int clockid, int flags, struct itimerspec *utmr,
struct itimerspec *outmr)
{
return syscall(__NR_timerfd, ufd, clockid, flags, utmr, outmr);
}

*/


/*
int timerfd_settime(int ufd, int flags,
> > const struct itimerspec *utmr,
> > struct itimerspec *otmr);
> > int timerfd_gettime(int ufd, struct itimerspec *otmr)
*/
#define TFD_TIMER_ABSTIME (1 << 0)



// #include 
#include 
#include 
#include 
#include 
#include  /* Definition of uint32_t */

#define die(msg) do { perror(msg); exit(EXIT_FAILURE); } while (0)

static void
print_elapsed_time(void)
{
static struct timespec start;
struct timespec curr;
static int first_call = 1;
int secs, nsecs;

if (first_call) {
first_call = 0;
if (clock_gettime(CLOCK_MONOTONIC, ) == -1)
die("clock_gettime");
}

if (clock_gettime(CLOCK_MONOTONIC, ) == -1)
die("clock_gettime");

secs = curr.tv_sec - start.tv_sec;
nsecs = curr.tv_nsec - start.tv_nsec;
if (nsecs < 0) {
secs--;
nsecs += 10;
}
printf("%d.%03d: ", secs, (nsecs + 50) / 100);
}

int
main(int argc, char *argv[])
{
struct itimerspec utmr, outmr;
int ufd;
struct timespec now;
int j, s;
uint64_t exp;
time_t start;

if (argc < 2) {
fprintf(stderr, "%s init-secs [interval-secs]\n",
argv[0]);
exit(EXIT_FAILURE);
}

if (clock_gettime(CLOCK_REALTIME, ) == -1)
die("clock_gettime");

/* Create a CLOCK_REALTIME absolute timer with initial
   expiration and interval as specified in command line */

utmr.it_value.tv_sec = now.tv_sec + atoi(argv[1]);
utmr.it_value.tv_nsec = now.tv_nsec;
if (argc == 2) {
utmr.it_interval.tv_sec = 0;
} else {
utmr.it_interval.tv_sec = atoi(argv[2]);
}
utmr.it_interval.tv_nsec = 0;

ufd = timerfd_create(CLOCK_REALTIME);
if (ufd == -1)
die("timerfd");
s = timerfd_settime(ufd, TFD_TIMER_ABSTIME, , NULL);
if (ufd == -1)
die("timerfd");

start = time(NULL);
for (j = 0; ; j++) {
sleep(1);
if (0 && (j % 10) == 0) {
printf("Resetting timer\n");
utmr.it_value.tv_sec += 1;
utmr.it_interval.tv_sec += 2;
s = timerfd_settime(ufd, 0, , );
if (s == -1)
die("timerfd-2");

}
s = timerfd_gettime(ufd, );
printf("Retrieval %3d (%3ld) - Got: %ld %ld; %ld %ld\n",
j, (long) (time(NULL) - start),
(long) outmr.it_value.tv_sec,
(long) outmr.it_value.tv_nsec,
(long) outmr.it_interval.tv_sec,
(long) outmr.it_interval.tv_nsec);
if ((j % 30) == 0 && j > 0) {
printf("About to read\n");
s = read(ufd, , sizeof(uint64_t));
if (s != sizeof(uint64_t))
die("read");
printf("Read: %lld\n", exp);
}
}

exit(EXIT_SUCCESS);
}

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

Re: [PATCH RFC 3/9] RCU: Preemptible RCU

[Oleg Nesterov]

On 09/10, Paul E. McKenney wrote:
>
> Work in progress, not for inclusion.

Impressive work! a couple of random newbie's questions...

> --- linux-2.6.22-b-fixbarriers/include/linux/rcupdate.h   2007-07-19 
> 14:02:36.0 -0700
> +++ linux-2.6.22-c-preemptrcu/include/linux/rcupdate.h2007-08-22 
> 15:21:06.0 -0700
>
>  extern void rcu_check_callbacks(int cpu, int user);

Also superfluously declared in rcuclassic.h and in rcupreempt.h

> --- linux-2.6.22-b-fixbarriers/include/linux/rcupreempt.h 1969-12-31 
> 16:00:00.0 -0800
> +++ linux-2.6.22-c-preemptrcu/include/linux/rcupreempt.h  2007-08-22 
> 15:21:06.0 -0700
> +
> +#define __rcu_read_lock_nesting()(current->rcu_read_lock_nesting)

unused?

> diff -urpNa -X dontdiff linux-2.6.22-b-fixbarriers/kernel/rcupreempt.c 
> linux-2.6.22-c-preemptrcu/kernel/rcupreempt.c
> --- linux-2.6.22-b-fixbarriers/kernel/rcupreempt.c1969-12-31 
> 16:00:00.0 -0800
> +++ linux-2.6.22-c-preemptrcu/kernel/rcupreempt.c 2007-08-22 
> 15:35:19.0 -0700
>
> +static DEFINE_PER_CPU(struct rcu_data, rcu_data);
> +static struct rcu_ctrlblk rcu_ctrlblk = {
> + .fliplock = SPIN_LOCK_UNLOCKED,
> + .completed = 0,
> +};
> static DEFINE_PER_CPU(int [2], rcu_flipctr) = { 0, 0 };

Just curious, any reason why rcu_flipctr can't live in rcu_data ? Similarly,
rcu_try_flip_state can be a member of rcu_ctrlblk, it is even protected by
rcu_ctrlblk.fliplock

Isn't DEFINE_PER_CPU_SHARED_ALIGNED better for rcu_flip_flag and rcu_mb_flag?

> +void __rcu_read_lock(void)
> +{
> + int idx;
> + struct task_struct *me = current;
> + int nesting;
> +
> + nesting = ORDERED_WRT_IRQ(me->rcu_read_lock_nesting);
> + if (nesting != 0) {
> +
> + /* An earlier rcu_read_lock() covers us, just count it. */
> +
> + me->rcu_read_lock_nesting = nesting + 1;
> +
> + } else {
> + unsigned long oldirq;
> +
> + /*
> +  * Disable local interrupts to prevent the grace-period
> +  * detection state machine from seeing us half-done.
> +  * NMIs can still occur, of course, and might themselves
> +  * contain rcu_read_lock().
> +  */
> +
> + local_irq_save(oldirq);

Could you please tell more, why do we need this cli?

It can't "protect" rcu_ctrlblk.completed, and the only change which affects
the state machine is rcu_flipctr[idx]++, so I can't understand the "half-done"
above. (of course, we must disable preemption while changing rcu_flipctr).

Hmm... this was already discussed... from another message:

> Critical portions of the GP protection happen in the scheduler-clock
> interrupt, which is a hardirq.  For example, the .completed counter
> is always incremented in hardirq context, and we cannot tolerate a
> .completed increment in this code.  Allowing such an increment would
> defeat the counter-acknowledge state in the state machine.

Still can't understand, please help! .completed could be incremented by
another CPU, why rcu_check_callbacks() running on _this_ CPU is so special?

> +
> + /*
> +  * Outermost nesting of rcu_read_lock(), so increment
> +  * the current counter for the current CPU.  Use volatile
> +  * casts to prevent the compiler from reordering.
> +  */
> +
> + idx = ORDERED_WRT_IRQ(rcu_ctrlblk.completed) & 0x1;
> + smp_read_barrier_depends();  /*  might be unneeded */
> + ORDERED_WRT_IRQ(__get_cpu_var(rcu_flipctr)[idx])++;

Isn't it "obvious" that this barrier is not needed? rcu_flipctr could be
change only by this CPU, regardless of the actual value of idx, we can't
read the "wrong" value of rcu_flipctr[idx], no?

OTOH, I can't understand how it works. With ot without local_irq_save(),
another CPU can do rcu_try_flip_idle() and increment rcu_ctrlblk.completed
at any time, we can see the old value... rcu_try_flip_waitzero() can miss us?

OK, GP_STAGES > 1, so rcu_try_flip_waitzero() will actually check both
0 and 1 lastidx's before synchronize_rcu() succeeds... I doubt very much
my understanding is correct. Apart from this why GP_STAGES > 1 ???

Well, I think this code is just too tricky for me! Will try to read again
after sleep ;)

> +static int
> +rcu_try_flip_idle(void)
> +{
> + int cpu;
> +
> + RCU_TRACE_ME(rcupreempt_trace_try_flip_i1);
> + if (!rcu_pending(smp_processor_id())) {
> + RCU_TRACE_ME(rcupreempt_trace_try_flip_ie1);
> + return 0;
> + }
> +
> + /*
> +  * Do the flip.
> +  */
> +
> + RCU_TRACE_ME(rcupreempt_trace_try_flip_g1);
> + rcu_ctrlblk.completed++;  /* stands in for rcu_try_flip_g2 */
> +
> + /*
> +  * Need a memory barrier so that other CPUs see the new
> +  * counter value before they see the subsequent change of all
> +  * the rcu_flip_flag 

2.6.23-rc7-git3: MTD cafe_nand warning

[Carl-Daniel Hailfinger]

Hi,

when compiling 2.6.23-rc7-git3 with a config which resembles
allmodconfig, I get the following warning in modpost:

WARNING: Can't handle masks in drivers/mtd/nand/cafe_nand:0

Regards,
Carl-Daniel

-
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: memset as memzero

[Linus Torvalds]

On Sun, 23 Sep 2007, Arnaldo Carvalho de Melo wrote:
> 
> bzero! That is it, its nothing new, just a sane name to something [..]

No, please no!

The BSD memory functions are nasty. If you do bzero, you logically should 
do the others too, and they are way inferior to the standard ones. Let's 
not go there.

Besides, if we want to avoid mistakes, I would suggest going to a much 
higher level. Ie more along the lines of also fixing the size and 
alignment, and using something like

#define memclear(p) memset(p, 0, sizeof(*(p)))

because if you actually do something like

git grep 'memset.*,[]*0[]*,'

(those [..] things contatain a space and a tab), you'll see that a *lot* 
of them share that pattern. 

Not that I think it's really worth it.

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

[PATCH] sysfs: backport of sysfs_readdir fix from 2.6.22.y to 2.6.16.y (CVE-2007-3104)

[Miloslav Semler]

This patch solves CVE-2007-3104  - sysfs_readdir oops.
More can be found here: 
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=commit;h=dc351252b33f8fede396d6173dba117bcb933607


Signed-off-by: Miloslav Semler
---
diff -uprN linux-2.6.16.53/fs/sysfs/dir.c linux-2.6.16.53-new/fs/sysfs/dir.c
--- linux-2.6.16.53/fs/sysfs/dir.c  2007-07-25 23:05:45.0 +0200
+++ linux-2.6.16.53-new/fs/sysfs/dir.c  2007-09-23 18:18:09.0 +0200
@@ -29,6 +29,14 @@ static struct dentry_operations sysfs_de
   .d_iput = sysfs_d_iput,
};

+static unsigned int sysfs_inode_counter;
+ino_t sysfs_get_inum(void)
+{
+   if (unlikely(sysfs_inode_counter < 3))
+   sysfs_inode_counter = 3;
+   return sysfs_inode_counter++;
+}
+
/*
 * Allocates a new sysfs_dirent and links it to the parent sysfs_dirent
 */
@@ -40,8 +48,10 @@ static struct sysfs_dirent * sysfs_new_d
   sd = kmem_cache_alloc(sysfs_dir_cachep, GFP_KERNEL);
   if (!sd)
   return NULL;
+

   memset(sd, 0, sizeof(*sd));
+   sd->s_ino = sysfs_get_inum();
   atomic_set(>s_count, 1);
   INIT_LIST_HEAD(>s_children);
   list_add(>s_sibling, _sd->s_children);
@@ -385,7 +395,7 @@ static int sysfs_readdir(struct file * f

   switch (i) {
   case 0:
-   ino = dentry->d_inode->i_ino;
+ino = parent_sd->s_ino;
   if (filldir(dirent, ".", 1, i, ino, DT_DIR) < 0)
   break;
   filp->f_pos++;
@@ -415,10 +425,7 @@ static int sysfs_readdir(struct file * f

   name = sysfs_get_name(next);
   len = strlen(name);
-   if (next->s_dentry)
-   ino = 
next->s_dentry->d_inode->i_ino;

-   else
-   ino = iunique(sysfs_sb, 2);
+ino = next->s_ino;

   if (filldir(dirent, name, len, 
filp->f_pos, ino,

dt_type(next)) < 0)
diff -uprN linux-2.6.16.53/fs/sysfs/inode.c 
linux-2.6.16.53-new/fs/sysfs/inode.c

--- linux-2.6.16.53/fs/sysfs/inode.c2007-07-25 23:05:45.0 +0200
+++ linux-2.6.16.53-new/fs/sysfs/inode.c2007-09-23 
18:18:09.0 +0200

@@ -119,6 +119,7 @@ struct inode * sysfs_new_inode(mode_t mo
   inode->i_mapping->a_ops = _aops;
   inode->i_mapping->backing_dev_info = 
_backing_dev_info;

   inode->i_op = _inode_operations;
+inode->i_ino = sd->s_ino;

   if (sd->s_iattr) {
   /* sysfs_dirent has non-default attributes
diff -uprN linux-2.6.16.53/fs/sysfs/mount.c 
linux-2.6.16.53-new/fs/sysfs/mount.c

--- linux-2.6.16.53/fs/sysfs/mount.c2007-07-25 23:05:45.0 +0200
+++ linux-2.6.16.53-new/fs/sysfs/mount.c2007-09-23 
18:18:09.0 +0200

@@ -29,6 +29,7 @@ static struct sysfs_dirent sysfs_root =
   .s_element  = NULL,
   .s_type = SYSFS_ROOT,
   .s_iattr= NULL,
+.s_ino  = 1,
};

static int sysfs_fill_super(struct super_block *sb, void *data, int silent)
diff -uprN linux-2.6.16.53/include/linux/sysfs.h 
linux-2.6.16.53-new/include/linux/sysfs.h
--- linux-2.6.16.53/include/linux/sysfs.h   2007-07-25 
23:05:45.0 +0200
+++ linux-2.6.16.53-new/include/linux/sysfs.h   2007-09-23 
18:18:09.0 +0200

@@ -72,6 +72,7 @@ struct sysfs_dirent {
   void* s_element;
   int s_type;
   umode_t s_mode;
+ino_t   s_ino;
   struct dentry   * s_dentry;
   struct iattr* s_iattr;
};
-
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: memset as memzero

[Arnaldo Carvalho de Melo]

Em Sun, Sep 23, 2007 at 12:33:13PM -0400, Robert P. J. Day escreveu:
> On Sun, 23 Sep 2007, Dave Jones wrote:
> 
> > There is one useful argument for memzero (or bzero to give it its
> > proper name), and that's that it's impossible to screw up. I'm still
> > amazed at how many times I see
> >
> > memset (x,size,0);
> >
> > in various code. So much so, that my editor highlights it now to
> > spot it during code review.  As does my mail client.  To be on the
> > safe side, I also have a cron job grepping for it in my
> > ~/Mail/commits for all the projects I'm interested in.
> 
>   taking a step back, regardless of what constitutes a sane versus
> not-sane definition of a useful macro, i think a lot of the content of
> kernel.h could be moved out of there and put in a more appropriate
> header file called, say, macros.h.
> 
>   the first comment in kernel.h claims that
> 
> /*
>  * 'kernel.h' contains some often-used function prototypes etc
>  */
> 
> but there's buckets more stuff in there than just some function
> prototypes.  macros for type limits, alignment, array sizes, rounding,
> and on and on.  and as for those prototypes, is there any reason that
> kernel.h includes them explicitly for the contents of lib/vsprintf.c
> rather than just including, say, a hypothetical vsprintf.h?  just
> curious.
> 
> in any case, it would seem that kernel.h could stand a good cleaning.
> it give the impression of just being an arbitrary dumping ground when
> folks can't figure out where to put something.

In an ideal world kernel.h has no place, I guess. I guess too that
janitors could make the world ideal in that respect. Keep moving things
from there to the right place. Don't do it every other day tho. People
find it annoying.

- Arnaldo
-
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.23-rc7 + radeonfb/s2ram

[Mihai Donțu]

On Sunday 23 September 2007, Benjamin Herrenschmidt wrote:
> Heh, yup.
> 
> There have been some radeonfb patches around -rc6 or so. Can you try
> backing them out and letting us know if that helps a) ?
> 
> In that case, Linus, we probably want to revert them...
> 
> Though looking at your PCI ID (5955), I don't think the patches should
> have changed anything.

After four hours of bisecting, I got this, which dates back to 2.6.21, but
I've been on 2.6.21.3 for too long and thus missed the commit (I just decided
to be a good citizen and test things before they get out).

dd1447134454b169d5ae353aceb93f2368db8547 is first bad commit
commit dd1447134454b169d5ae353aceb93f2368db8547
Author: johan henriksson <[EMAIL PROTECTED]>
Date:   Tue May 8 00:37:59 2007 -0700

radeonfb: Add support for Radeon xpress 200m

Added support for radeon xpress 200m(rs480).  Note that the card doesn't
like dynclk turned on.

Signed-off-by: Johan Henriksson <[EMAIL PROTECTED]>
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Cc: "Antonino A. Daplas" <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>

:04 04 e553664a656ee329152789818b5b071a36ac1e45 
0a698ad7daa8cdfd9eb5304812845306c9feb2f9 M  drivers

I turned dynclk off, no result (although dynclk is preferred).

What is interesting, is that the driver ignores "vga=normal" and "jumps" to
a quite high res (I think is 1024x768 or something; the fonts look really nice
though :)).

-- 
Mihai Donțu
-
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: memset as memzero

[Robert P. J. Day]

On Sun, 23 Sep 2007, Dave Jones wrote:

> There is one useful argument for memzero (or bzero to give it its
> proper name), and that's that it's impossible to screw up. I'm still
> amazed at how many times I see
>
>   memset (x,size,0);
>
> in various code. So much so, that my editor highlights it now to
> spot it during code review.  As does my mail client.  To be on the
> safe side, I also have a cron job grepping for it in my
> ~/Mail/commits for all the projects I'm interested in.

  taking a step back, regardless of what constitutes a sane versus
not-sane definition of a useful macro, i think a lot of the content of
kernel.h could be moved out of there and put in a more appropriate
header file called, say, macros.h.

  the first comment in kernel.h claims that

/*
 * 'kernel.h' contains some often-used function prototypes etc
 */

but there's buckets more stuff in there than just some function
prototypes.  macros for type limits, alignment, array sizes, rounding,
and on and on.  and as for those prototypes, is there any reason that
kernel.h includes them explicitly for the contents of lib/vsprintf.c
rather than just including, say, a hypothetical vsprintf.h?  just
curious.

in any case, it would seem that kernel.h could stand a good cleaning.
it give the impression of just being an arbitrary dumping ground when
folks can't figure out where to put something.

rday
-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca

-
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 2/3] cxacru: Reduce initialisation delay

[Duncan Sands]

Hi Simon,

> + usb_info(usbatm, "started firmware\n");
...
> + usb_info(usbatm, "loaded config data\n");

maybe these should be debug messages.  When are they useful?

Ciao,

Duncan.
-
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: Memory allocation problem with 2.6.22 after suspend/resume cycle

[Christian P. Schmidt]

Rafael J. Wysocki wrote:
> On Sunday, 23 September 2007 14:38, Christian P. Schmidt wrote:
>> Rafael J. Wysocki wrote:
>>> On Saturday, 22 September 2007 17:41, Christian P. Schmidt wrote:
 Hi all,

 I'm having a strange problem, of course not reproducible. Sometimes
 after a suspend (to ram) and resume cycle, the kernel will try to free
 all memory. This means, all running applications are flushed to swap (as
 long as it is available), caches and buffers stay at around 15MB each.

 The following video (traded quality for bandwidth) shows what happens on
 the way from no swap to "swapon -a" (that's the unreadable thing in the
 small shell): http://digadd.de/swapping.avi

 The system:
 Linux dnnote 2.6.22.5 #1 SMP PREEMPT Sat Aug 25 18:39:21 AST 2007 x86_64
 Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz GenuineIntel GNU/Linux
>>> Are you using an ATI binary graphics driver?
>> Yes. I do not (yet) have a choice... can't wait for the open source drivers.
> 
> That, most probably, is the source of the problem.  Please see:
> http://bugzilla.kernel.org/show_bug.cgi?id=8943

I do however not agree with Andrew's conclusion, as the memory is not
"used", so I wouldn't expect a memory leak. As soon as I turn swapping
off everything is loaded again, and works. If there was a leak it should
use the memory, shouldn't it?
If the problem would be 100% reproducible I could try without, but as
is, I have up to two weeks with 2-3 cycles daily (sometimes more, as I
receive untraceable SERR from my PCI-E WLAN after which I do not receive
interrupts any more - only a suspend/resume cycle helps...) before the
problem occurs.

Anyway, is there a way of unloading the module temporarily without
shutting X down?

 A 32bit Kernel is unable to suspend/resume at all. No idea why. dmesg
 shows nothing, logs show nothing. Any ideas for debugging are welcome.
>>> Well, that's interesting.
>>>
>>> Can you try in the minimal configuration (ie. boot with init=/bin/bash,
>>> mount /sys, mount /proc and run "echo mem > /sys/power/disk)?
>> Which? the 32bit or the 64bit?
> 
> 32-bit, but please do that without the ATI driver.

Did it. As before, suspends, but when I resume, I hear the CD-ROM spin
up, the backlight comes on, and nothing more. The system is a Lenovo
Thinkpad T60 8744-4XG, BIOS 1.09.

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

Re: [PATCH 3/3] cxacru: Cleanup code by removing "ret = ret;" assignments

[Duncan Sands]

On Sunday 23 September 2007 17:36:08 Simon Arlott wrote:
> Cleanup code by removing "ret = ret;" assignments.
> 
> Signed-Off-By: Simon Arlott <[EMAIL PROTECTED]>

Acked-by: Duncan Sands <[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: [PATCH 1/2] cxacru: Use appropriate logging for errors

[Duncan Sands]

Hi Simon, don't these error messages (except the first) risk spamming
the log if something goes wrong (like the modem being unplugged)?  How
about rate-limiting them, like usbatm does?

Ciao,

Duncan.
-
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: memset as memzero

[Arnaldo Carvalho de Melo]

Em Sun, Sep 23, 2007 at 11:32:43AM -0400, Dave Jones escreveu:
> On Sat, Sep 22, 2007 at 11:53:53AM -0700, Linus Torvalds wrote:
>  > 
>  > 
>  > On Sat, 22 Sep 2007, Arjan van de Ven wrote:
>  > > 
>  > > it doesn't add value memset with a constant 0 is just as fast
>  > > (since the compiler knows it's 0) than any wrapper around it, and the
>  > > syntax around it is otherwise the same.
>  > 
>  > Indeed.
>  > 
>  > The reason we have "clear_page()" is not because the value we're writing 
>  > is constant - that doesn't really help/change anything at all. We could 
>  > have had a "fill_page()" that sets the value to any random byte, it's just 
>  > that zero is the only value that we really care about.
>  > 
>  > So the reason we have "clear_page()" is because the *size* and *alignment* 
>  > is constant and known at compile time, and unlike the value you write, 
>  > that actually matters.
>  > 
>  > So "memzero()" would never really make sense as anything but a syntactic 
>  > wrapper around "memset(x,0,size)". 
> 
> There is one useful argument for memzero (or bzero to give it its proper
> name), and that's that it's impossible to screw up.
> I'm still amazed at how many times I see
> 
>   memset (x,size,0);
> 
> in various code. So much so, that my editor highlights it now to spot
> it during code review.  As does my mail client.  To be on the safe
> side, I also have a cron job grepping for it in my ~/Mail/commits
> for all the projects I'm interested in.
> 
> It's tragic really just how easy it is to screw it up.

bzero! That is it, its nothing new, just a sane name to something that
is useful to humans, even being of sheer arrogant disdain for machines
as a useless stuff only humans couldn't get right. Yeah, us screw up
pretty much more than them.

- Arnaldo
-
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: [git] CFS-devel, updates

[Mike Galbraith]

On Sun, 2007-09-23 at 13:58 +0200, Ingo Molnar wrote:

> i'm also wondering - do we even need sync_vruntime() at all? Now that we 
> fix up vruntime while we migrate tasks across rqs, the global notion of 
> vruntime makes less and less of a sense.

Yeah, I was wondering that too, but it does seem to be needed.  If I
make it a noop, and run the pinned tasks with an unpinned make -j2 test,
Xorg at nice -5 still takes hits...

se.wait_max  :11.513462
se.wait_max  : 6.250911
se.wait_max  :15.181511
se.wait_max  :   188.963625
se.wait_max  : 4.951569
se.wait_max  :11.391749

...which begs the question "gee, what happens if I pin a nice 0 hog to
CPU0, and a nice 19 hog to CPU1 with the queues never ever syncing?".

The answer to that one seems to be "Don't even think about it!".  This
needs more investigation... there's gotta be a 32 bit thingie hiding in
there.  I lost control for a few seconds, got it back, then lost it
again forever (sysrq-b worked though, hmm).

-Mike

-
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: What's in linux-2.6-block.git for 2.6.24

[Torsten Kaiser]

On 9/23/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> > Sep 18 18:50:01 treogen [   63.44] ata1.00: status: {DRDY }
> > Sep 18 18:50:01 treogen [   63.44] ata1: hard resetting link
>
> Timed out waiting for data transfers to complete that didn't. Does sound
> like the device got told the wrong sized transfer.
>
>
> It then falls off the bus because Jeff hasn't merged Mark Lord's DRQ
> draining patch.

One time the error was different:
Sep 11 19:19:24 treogen [   33.34] ata1.00: exception Emask 0x20
SAct 0x1 SErr 0x0 action 0x2
Sep 11 19:19:24 treogen [   33.34] ata1.00: irq_stat 0x00020002,
PCI master abort while fetching SGT
Sep 11 19:19:24 treogen [   33.34] ata1.00: cmd
61/08:00:09:d6:42/00:00:25:00:00/40 tag 0 cdb 0x0 data 4096 out
Sep 11 19:19:24 treogen [   33.34]  res
50/00:00:af:ea:42/00:00:25:00:00/e0 Emask 0x20 (host bus error)
Sep 11 19:19:24 treogen [   33.34] ata1.00: status: {DRDY }
Sep 11 19:19:24 treogen [   33.67] ata1: soft resetting link
Sep 11 19:19:24 treogen [   33.71] ata1: SATA link up 3.0 Gbps
(SStatus 123 SControl 300)
Sep 11 19:19:24 treogen [   33.80] ata1.00: configured for UDMA/100
Sep 11 19:19:24 treogen [   33.80] ata1: EH complete

This was repeated 12 times.
(Diff between a good boot and one with that error is here:
http://lkml.org/lkml/2007/9/14/107 )

Torsten
-
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] cxacru: Reduce initialisation delay

[Simon Arlott]

Since card status updates appear to only occur every second, a delay
of 1000ms on startup may not be sufficient - change to 1500ms.

The long delay of 4000ms is likely to be related to the time required
for the ADSL line to come up - the driver should not need to do this.

Overall delay when loading firmware will change from 5000ms to 1500ms.

Signed-Off-By: Simon Arlott <[EMAIL PROTECTED]>
---
 drivers/usb/atm/cxacru.c |9 +
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/atm/cxacru.c b/drivers/usb/atm/cxacru.c
index 8d8a107..35308a8 100644
--- a/drivers/usb/atm/cxacru.c
+++ b/drivers/usb/atm/cxacru.c
@@ -931,9 +931,10 @@ static void cxacru_upload_firmware(struct cxacru_data 
*instance,
usb_err(usbatm, "Passing control to firmware failed: %d\n", 
ret);
return;
}
+   usb_info(usbatm, "started firmware\n");
 
/* Delay to allow firmware to start up. */
-   msleep_interruptible(1000);
+   msleep(1500);
 
usb_clear_halt(usb_dev, usb_sndbulkpipe(usb_dev, CXACRU_EP_CMD));
usb_clear_halt(usb_dev, usb_rcvbulkpipe(usb_dev, CXACRU_EP_CMD));
@@ -947,7 +948,7 @@ static void cxacru_upload_firmware(struct cxacru_data 
*instance,
}
 
/* Load config data (le32), doing one packet at a time */
-   if (cf)
+   if (cf) {
for (off = 0; off < cf->size / 4; ) {
u32 buf[CMD_PACKET_SIZE / 4 - 1];
int i, len = min_t(int, cf->size / 4 - off, 
CMD_PACKET_SIZE / 4 / 2 - 1);
@@ -963,8 +964,8 @@ static void cxacru_upload_firmware(struct cxacru_data 
*instance,
return;
}
}
-
-   msleep_interruptible(4000);
+   usb_info(usbatm, "loaded config data\n");
+   }
 }
 
 static int cxacru_find_firmware(struct cxacru_data *instance,
-- 
1.5.0.1

-- 
Simon Arlott
-
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 3/3] cxacru: Cleanup code by removing "ret = ret;" assignments

[Simon Arlott]

Cleanup code by removing "ret = ret;" assignments.

Signed-Off-By: Simon Arlott <[EMAIL PROTECTED]>
---
 drivers/usb/atm/cxacru.c |4 
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/atm/cxacru.c b/drivers/usb/atm/cxacru.c
index 35308a8..bb3169c 100644
--- a/drivers/usb/atm/cxacru.c
+++ b/drivers/usb/atm/cxacru.c
@@ -496,7 +496,6 @@ static int cxacru_cm(struct cxacru_data *instance, enum 
cxacru_cm_request cm,
if (ret < 0) {
usb_err(instance->usbatm, "submit of read urb for cm %#x failed 
(%d)\n",
cm, ret);
-   ret = ret;
goto fail;
}
 
@@ -514,21 +513,18 @@ static int cxacru_cm(struct cxacru_data *instance, enum 
cxacru_cm_request cm,
if (ret < 0) {
usb_err(instance->usbatm, "submit of write urb for cm %#x 
failed (%d)\n",
cm, ret);
-   ret = ret;
goto fail;
}
 
ret = cxacru_start_wait_urb(instance->snd_urb, >snd_done, 
NULL);
if (ret < 0) {
usb_err(instance->usbatm, "send of cm %#x failed (%d)\n", cm, 
ret);
-   ret = ret;
goto fail;
}
 
ret = cxacru_start_wait_urb(instance->rcv_urb, >rcv_done, 
);
if (ret < 0) {
usb_err(instance->usbatm, "receive of cm %#x failed (%d)\n", 
cm, ret);
-   ret = ret;
goto fail;
}
if (actlen % CMD_PACKET_SIZE || !actlen) {
-- 
1.5.0.1

-- 
Simon Arlott
-
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: memset as memzero

[Dave Jones]

On Sat, Sep 22, 2007 at 11:53:53AM -0700, Linus Torvalds wrote:
 > 
 > 
 > On Sat, 22 Sep 2007, Arjan van de Ven wrote:
 > > 
 > > it doesn't add value memset with a constant 0 is just as fast
 > > (since the compiler knows it's 0) than any wrapper around it, and the
 > > syntax around it is otherwise the same.
 > 
 > Indeed.
 > 
 > The reason we have "clear_page()" is not because the value we're writing 
 > is constant - that doesn't really help/change anything at all. We could 
 > have had a "fill_page()" that sets the value to any random byte, it's just 
 > that zero is the only value that we really care about.
 > 
 > So the reason we have "clear_page()" is because the *size* and *alignment* 
 > is constant and known at compile time, and unlike the value you write, 
 > that actually matters.
 > 
 > So "memzero()" would never really make sense as anything but a syntactic 
 > wrapper around "memset(x,0,size)". 

There is one useful argument for memzero (or bzero to give it its proper
name), and that's that it's impossible to screw up.
I'm still amazed at how many times I see

memset (x,size,0);

in various code. So much so, that my editor highlights it now to spot
it during code review.  As does my mail client.  To be on the safe
side, I also have a cron job grepping for it in my ~/Mail/commits
for all the projects I'm interested in.

It's tragic really just how easy it is to screw it up.

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: What's in linux-2.6-block.git for 2.6.24

[Torsten Kaiser]

On 9/23/07, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> On Sun, 23 Sep 2007 15:19:13 +0200
> "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> > To update the statistik:
> > prior to 2.6.23-rc4-mm1: no trouble with any drives on the SiI 3132.
> > 2.6.23-rc4-mm1 without patch: 2 out of 2 bad.
> > back to 2.6.23-rc3-mm1: 18x good.
> > 2.6.23-rc4-mm1 with patch:  2 out of 8 bad
> > after that second mail:
> > 2.6.23-rc4-mm1 with patch: 1 out of 5 bad
> > 2.6.23-rc6-mm1: 1 out of 2 bad
>
> git-block.patch in 2.6.23-rc6-mm1 includes my patch that disables sg
> chaining for libata but it still includes libata's sg chaining
> changes. So these changes breaks libata or libata was broken after
> 2.6.23-rc3-mm1.
>
> Can you try Jens's sglist-arch branch? If it works, probably libata in
> -mm has bugs.
>
> For your convenience, I put a sglist-arch branch patch against v2.6.23-rc7:
>
> http://www.kernel.org/pub/linux/kernel/people/tomo/misc/v2.6.23-rc7-sglist-arch.diff.bz2

Thanks for the patch.
I tried it and 3 out of 3 boot attempts worked without problems.
But I can't rule out that the bug is still there, as I have no way to
trigger it on demand.

Torsten
-
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/2] cxacru: Use appropriate logging for errors

[Simon Arlott]

When an error occurs, existing logging uses dbg() so the cause of a 
problem is hard to determine. Error conditions shouldn't only be 
properly reported with debugging enabled.

A side effect of this change is that when an uninitialised device 
is started, a log message similar to the following is sent:
cxacru 5-2:1.0: receive of cm 0x90 failed (-104)
This is normal - the device did not respond so firmware will be 
loaded.

Signed-Off-By: Simon Arlott <[EMAIL PROTECTED]>
---
This could be added to 2.6.23 since it only makes error logging 
more verbose.

 drivers/usb/atm/cxacru.c |   29 ++---
 1 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/atm/cxacru.c b/drivers/usb/atm/cxacru.c
index a73e714..8d8a107 100644
--- a/drivers/usb/atm/cxacru.c
+++ b/drivers/usb/atm/cxacru.c
@@ -482,7 +482,8 @@ static int cxacru_cm(struct cxacru_data *instance, enum 
cxacru_cm_request cm,
int rbuflen = ((rsize - 1) / stride + 1) * CMD_PACKET_SIZE;
 
if (wbuflen > PAGE_SIZE || rbuflen > PAGE_SIZE) {
-   dbg("too big transfer requested");
+   usb_err(instance->usbatm, "requested transfer size too large 
(%d, %d)\n",
+   wbuflen, rbuflen);
ret = -ENOMEM;
goto fail;
}
@@ -493,7 +494,8 @@ static int cxacru_cm(struct cxacru_data *instance, enum 
cxacru_cm_request cm,
init_completion(>rcv_done);
ret = usb_submit_urb(instance->rcv_urb, GFP_KERNEL);
if (ret < 0) {
-   dbg("submitting read urb for cm %#x failed", cm);
+   usb_err(instance->usbatm, "submit of read urb for cm %#x failed 
(%d)\n",
+   cm, ret);
ret = ret;
goto fail;
}
@@ -510,27 +512,28 @@ static int cxacru_cm(struct cxacru_data *instance, enum 
cxacru_cm_request cm,
init_completion(>snd_done);
ret = usb_submit_urb(instance->snd_urb, GFP_KERNEL);
if (ret < 0) {
-   dbg("submitting write urb for cm %#x failed", cm);
+   usb_err(instance->usbatm, "submit of write urb for cm %#x 
failed (%d)\n",
+   cm, ret);
ret = ret;
goto fail;
}
 
ret = cxacru_start_wait_urb(instance->snd_urb, >snd_done, 
NULL);
if (ret < 0) {
-   dbg("sending cm %#x failed", cm);
+   usb_err(instance->usbatm, "send of cm %#x failed (%d)\n", cm, 
ret);
ret = ret;
goto fail;
}
 
ret = cxacru_start_wait_urb(instance->rcv_urb, >rcv_done, 
);
if (ret < 0) {
-   dbg("receiving cm %#x failed", cm);
+   usb_err(instance->usbatm, "receive of cm %#x failed (%d)\n", 
cm, ret);
ret = ret;
goto fail;
}
if (actlen % CMD_PACKET_SIZE || !actlen) {
-   dbg("response is not a positive multiple of %d: %#x",
-   CMD_PACKET_SIZE, actlen);
+   usb_err(instance->usbatm, "invalid response length to cm %#x: 
%d\n",
+   cm, actlen);
ret = -EIO;
goto fail;
}
@@ -538,12 +541,14 @@ static int cxacru_cm(struct cxacru_data *instance, enum 
cxacru_cm_request cm,
/* check the return status and copy the data to the output buffer, if 
needed */
for (offb = offd = 0; offd < rsize && offb < actlen; offb += 
CMD_PACKET_SIZE) {
if (rbuf[offb] != cm) {
-   dbg("wrong cm %#x in response", rbuf[offb]);
+   usb_err(instance->usbatm, "wrong cm %#x in response to 
cm %#x\n",
+   rbuf[offb], cm);
ret = -EIO;
goto fail;
}
if (rbuf[offb + 1] != CM_STATUS_SUCCESS) {
-   dbg("response failed: %#x", rbuf[offb + 1]);
+   usb_err(instance->usbatm, "response to cm %#x failed: 
%#x\n",
+   cm, rbuf[offb + 1]);
ret = -EIO;
goto fail;
}
@@ -582,14 +587,16 @@ static int cxacru_cm_get_array(struct cxacru_data 
*instance, enum cxacru_cm_requ
for (offb = 0; offb < len; ) {
int l = le32_to_cpu(buf[offb++]);
if (l > stride || l > (len - offb) / 2) {
-   dbg("wrong data length %#x in response", l);
+   usb_err(instance->usbatm, "invalid data length from cm 
%#x: %d\n",
+   cm, l);
ret = -EIO;
goto cleanup;
}
while (l--) {
offd = le32_to_cpu(buf[offb++]);
if (offd >= size) {
-   dbg("wrong index %#x in response", offd);
+   

Re: 2.6.23-rc6-mm1 -- ipg.c don't compile on i386 with CONFIG_HIGHMEM64G

[trem]

Hi

I've tried to compile 2.6.23-rc6-mm1, but it fails on ipg.c with the error :
Setup is 10964 bytes (padded to 11264 bytes).
System is 1640 kB
Kernel: arch/i386/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 2030 modules
WARNING: Can't handle masks in drivers/mtd/nand/cafe_nand:0
ERROR: "__udivdi3" [drivers/net/ipg.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
error: Bad exit status from /home/trem/rpm/tmp/rpm-tmp.23895 (%build)

I've instigated a bit, and I've found this code in ipg.c :

static void ipg_nic_txfree(struct net_device *dev)
{
   struct ipg_nic_private *sp = netdev_priv(dev);
   void __iomem *ioaddr = sp->ioaddr;
   const unsigned int curr = ipg_r32(TFD_LIST_PTR_0) -
   (sp->txd_map / sizeof(struct ipg_tx)) - 1;
   unsigned int released, pending;



sp->txd_map is an u64
because :
dma_addr_t txd_map;

And in asm-i386/types.h, I see :
#ifdef CONFIG_HIGHMEM64G
typedef u64 dma_addr_t;
#else
typedef u32 dma_addr_t;
#endif
I my config, I use CONFIG_HIGHMEM64G

sizeof(struct ipg_tx) is an u32
So the div failed on i386 because of u64 / u32.

I propose the following patch :

--- linux-2.6.22.old/drivers/net/ipg.c  2007-09-21 20:28:57.0 -0400
+++ linux-2.6.22.new/drivers/net/ipg.c  2007-09-21 20:22:15.0 -0400
@@ -837,7 +837,7 @@ static void ipg_nic_txfree(struct net_de
struct ipg_nic_private *sp = netdev_priv(dev);
void __iomem *ioaddr = sp->ioaddr;
const unsigned int curr = ipg_r32(TFD_LIST_PTR_0) -
-   (sp->txd_map / sizeof(struct ipg_tx)) - 1;
+   do_div(sp->txd_map , sizeof(struct ipg_tx)) - 1;
unsigned int released, pending;

IPG_DEBUG_MSG("_nic_txfree\n");


With this patch, it compiles on i386 and x86_64, but I haven't tested if
this network card works (I don't have it).


regards,
trem

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

Needed: advansys driver testers

[Matthew Wilcox]

I've removed all uses of bus_to_virt[1] and virt_to_bus from the advansys
driver for the narrow card; it's now at the point where I can get 8MB/s
on a parisc machine [2].  But I don't have a wide advansys card, and the code
paths in the driver are very, very different.  I think I know everything
that needs to be done to make it work, but not having a card to test with,
and not being infallible makes life tricky.

So, anyone got a *wide* advansys card that they would like to test with?
Bonus points if you have ethnic hardware to plug it into; something with
an IOMMU like ia64, parisc or sparc64 would be a real bonus.  Or if you
have such a card, and don't want it any more, I'll take it off your hands.

[1] A highly evil interface from the bad old days when machines only had
one bus and no iommus.
[2] 10MHz bus, 8 bits wide ... I'm at 80% bus utilisation, that's not too
shabby.  I've not looked into performance yet, only getting it working.
I've got a scsi analyser, and this seems like a great opportunity to
learn how to use it.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
-
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 0/2] suspend/resume regression fixes

[Matthew Garrett]

On Sat, Sep 22, 2007 at 08:11:06PM -0700, Linus Torvalds wrote:

> From a "future behaviour" standpoint it would probably be interesting to 
> hear whether Mihai can make his machine with not with the old IDE layer 
> (which distributions are migrating away from) but with the ATA layer 
> (libata) instead. It too should hopefully know about using ACPI to restore 
> any ATA controller quirks.

It does, but it's disabled by default. libata needs to be loaded with 
noacpi=0.

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