All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: False OOM with swappiness == 0
From: Mikulas Patocka @ 2006-04-03 16:13 UTC (permalink / raw)
  To: LKML
In-Reply-To: <Pine.LNX.4.64.0604031811270.7588@artax.karlin.mff.cuni.cz>

> Hi
>
> On one our server we've seen that OOM killer kills a process even if there's 
> plenty of free swap space. The server had swappiness set to 0 which probably 
> triggered the bug.
>
> Mikulas

I forgot to tell kernel version: 2.6.15-gentoo-r1. Dual Opteron with 4G 
RAM.

Mikulas

^ permalink raw reply

* Re: [linux-usb-devel] Problems with USB setup with Linux 2.6.16
From: Mark Lord @ 2006-04-03 16:12 UTC (permalink / raw)
  To: Joshua Kwan; +Cc: Alan Stern, linux-kernel, linux-usb-devel
In-Reply-To: <44309821.1090600@triplehelix.org>

Joshua Kwan wrote:
> On 04/02/2006 07:09 PM, Alan Stern wrote:
>> If you were to continue looking farther down in the log, you would find
>> that ehci-hcd sees all those devices.  Those that can run at high speed
>> continue using the EHCI controller.  For those that can't, the switch is 
>> reset and they get reconnected to their UHCI controller.
> 
> That makes sense - that is indeed what happens when it DOES work (i.e.
> with 2.6.15), but the fact is that they don't come back in 2.6.16. I
> will try building ehci-hcd in and see what happens.

Around 2.6.13, I noticed that EHCI stopped working after a suspend/resume
(to/from RAM) cycle.  So I updated my suspend script to unload/reload EHCI
each time, which fixed the problem for me.  My script still does that.

Dunno if it's fixed in mainline or not.
Does unloading/reloading EHCI help you?

   rmmod ehci_hcd ; modprobe ehci_hcd

Cheers

^ permalink raw reply

* False OOM with swappiness == 0
From: Mikulas Patocka @ 2006-04-03 16:12 UTC (permalink / raw)
  To: LKML

Hi

On one our server we've seen that OOM killer kills a process even if 
there's plenty of free swap space. The server had swappiness set to 0 
which probably triggered the bug.

Mikulas

^ permalink raw reply

* [PATCH] fix MIPS PFN/page borkage
From: Dave Hansen @ 2006-04-03 16:11 UTC (permalink / raw)
  To: ralf; +Cc: linux-kernel, Dave Hansen


The "unify PFN_* macros" patch screwed up and somehow modified
the MIPS code where it shouldn't have.  This backs those changes
back out.

Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
---

 work-dave/arch/mips/mips-boards/generic/memory.c |    4 ++--
 work-dave/arch/mips/mips-boards/sim/sim_mem.c    |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff -puN arch/mips/mips-boards/generic/memory.c~unify_PFN_macros arch/mips/mips-boards/generic/memory.c
--- work/arch/mips/mips-boards/generic/memory.c~unify_PFN_macros	2006-04-03 09:09:42.000000000 -0700
+++ work-dave/arch/mips/mips-boards/generic/memory.c	2006-04-03 09:09:42.000000000 -0700
@@ -106,10 +106,10 @@ struct prom_pmemblock * __init prom_getm
 
 	mdesc[3].type = yamon_dontuse;
 	mdesc[3].base = 0x00100000;
-	mdesc[3].size = CPHYSADDR(PAGE_ALIGN(&_end)) - mdesc[3].base;
+	mdesc[3].size = CPHYSADDR(PFN_ALIGN(&_end)) - mdesc[3].base;
 
 	mdesc[4].type = yamon_free;
-	mdesc[4].base = CPHYSADDR(PAGE_ALIGN(&_end));
+	mdesc[4].base = CPHYSADDR(PFN_ALIGN(&_end));
 	mdesc[4].size = memsize - mdesc[4].base;
 
 	return &mdesc[0];
diff -puN arch/mips/mips-boards/sim/sim_mem.c~unify_PFN_macros arch/mips/mips-boards/sim/sim_mem.c
--- work/arch/mips/mips-boards/sim/sim_mem.c~unify_PFN_macros	2006-04-03 09:09:42.000000000 -0700
+++ work-dave/arch/mips/mips-boards/sim/sim_mem.c	2006-04-03 09:09:42.000000000 -0700
@@ -61,10 +61,10 @@ struct prom_pmemblock * __init prom_getm
 
 	mdesc[2].type = simmem_reserved;
 	mdesc[2].base = 0x00100000;
-	mdesc[2].size = CPHYSADDR(PAGE_ALIGN(&_end)) - mdesc[2].base;
+	mdesc[2].size = CPHYSADDR(PFN_ALIGN(&_end)) - mdesc[2].base;
 
 	mdesc[3].type = simmem_free;
-	mdesc[3].base = CPHYSADDR(PAGE_ALIGN(&_end));
+	mdesc[3].base = CPHYSADDR(PFN_ALIGN(&_end));
 	mdesc[3].size = memsize - mdesc[3].base;
 
 	return &mdesc[0];
_

^ permalink raw reply

* Re: [RFC] install_session_keyring
From: Suzanne Wood @ 2006-04-03 16:11 UTC (permalink / raw)
  To: dhowells; +Cc: linux-kernel, paulmck

  > From David Howells Mon Apr  3 01:46:08 2006

  > Suzanne Wood <suzannew@cs.pdx.edu> wrote:

  > > In a study of the control flow graph dumps to check that 
  > > an rcu_assign_pointer() with a given argument type has 
  > > preceded a call to rcu_dereference(), I've come across 
  > > install_session_keyring() of security/keys/process_keys.c.  
  > > We note that although no rcu_read_lock() is in place 
  > > locally or in the function's kernel callers, siglock 
  > > likely addresses that.  While the rcu_dereference() would 
  > > indicate a desire for 'old' to persist, synchronize_rcu() 
  > > is called prior to key_put(old) which "disposes of 
  > > reference to a key."  The order of events with a use of 
  > > the copy of the pointer following synchronize_rcu() is 
  > > what I question.

  > Are you simply suggesting that the rcu_dereference() in:

  > 	/* install the keyring */
  >        	spin_lock_irqsave(&tsk->sighand->siglock, flags);
  >        	old = rcu_dereference(tsk->signal->session_keyring);
  >        	rcu_assign_pointer(tsk->signal->session_keyring, keyring);
  >        	spin_unlock_irqrestore(&tsk->sighand->siglock, flags);

  > is unnecessary?

Since RCU is applicable in read intensive environments and I
look for rcu_dereference() on the read side to be paired with
rcu_assign_pointer() on the update side, I wonder if key_put()
might be redundant or risky after synchronize_rcu(), because 
key_put() opens with if(key) and employs atomic_dec_and_test(&key->usage)) 
before schedule_work(&key_cleanup_task).  If the memory referenced 
by old has already been reclaimed which appears is made possible by 
synchronize_rcu(), it seems that there is a contention here.

Yes, so I guess you mean to get rid of 'old' altogether and the three
lines that refer to it.  But I think the original intent was to have
the former session keyring persist to some extent.
Thanks.
Suzanne 

  > If so, I think you are right since the pointer is only changed with the
  > siglock held[*], and so modify/modify conflict isn't a problem and doesn't
  > need memory barriers.

  > [*] Apart from during the exit() cleanup, when I don't think this should be a
  > problem anyway.

  > David


^ permalink raw reply

* [PATCH] Remove some dead code from xenconsole
From: Anthony Liguori @ 2006-04-03 16:11 UTC (permalink / raw)
  To: xen-devel

[-- Attachment #1: Type: text/plain, Size: 130 bytes --]

Remove some bit rot from the changes to the console driver over the 3.0 
series.  Only compile tested.

Regards,

Anthony Liguori

[-- Attachment #2: xenconsole-dead-code.diff --]
[-- Type: text/plain, Size: 1322 bytes --]

# HG changeset patch
# User Anthony Liguori <anthony@codemonkey.ws>
# Node ID e3e364456cac763c144468591df0528536b8cff4
# Parent  4ad317429111d43cc99810af25b3faf6ffed4209
Remove some dead code from the consoled client.

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

diff -r 4ad317429111 -r e3e364456cac tools/console/client/main.c
--- a/tools/console/client/main.c	Sun Apr  2 16:16:53 2006 +0100
+++ b/tools/console/client/main.c	Mon Apr  3 11:06:59 2006 -0500
@@ -36,7 +36,6 @@
 #include <errno.h>
 #include <pty.h>
 
-#include "xenctrl.h"
 #include "xs.h"
 
 #define ESCAPE_CHARACTER 0x1d
@@ -92,7 +91,7 @@
 	tcsetattr(fd, TCSAFLUSH, old);
 }
 
-static int console_loop(int xc_handle, domid_t domid, int fd)
+static int console_loop(int fd)
 {
 	int ret;
 
@@ -161,7 +160,6 @@
 {
 	struct termios attr;
 	int domid;
-	int xc_handle;
 	char *sopt = "h";
 	int ch;
 	int opt_ind=0;
@@ -206,11 +204,6 @@
 		err(errno, "Could not contact XenStore");
 	}
 
-	xc_handle = xc_interface_open();
-	if (xc_handle == -1) {
-		err(errno, "xc_interface_open()");
-	}
-	
 	signal(SIGTERM, sighandler);
 
 	path = xs_get_domain_path(xs, domid);
@@ -260,7 +253,7 @@
 	free(path);
 
 	init_term(STDIN_FILENO, &attr);
-	console_loop(xc_handle, domid, spty);
+	console_loop(spty);
 	restore_term(STDIN_FILENO, &attr);
 
 	return 0;

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply

* [PATCH -rt] have highres runqueue adjust_prio
From: Steven Rostedt @ 2006-04-03 16:07 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: Ingo Molnar, LKML

Currently, the low res runqueue in hrtimers calls adjust prio, but the
high res does not.

-- Steve

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

Index: linux-2.6.16-rt11/kernel/hrtimer.c
===================================================================
--- linux-2.6.16-rt11.orig/kernel/hrtimer.c	2006-03-30 08:28:18.000000000 -0500
+++ linux-2.6.16-rt11/kernel/hrtimer.c	2006-03-30 10:41:38.000000000 -0500
@@ -951,6 +951,7 @@
 			BUG_ON(hrtimer_active(timer));
 			enqueue_hrtimer(timer, base);
 		}
+		hrtimer_adjust_softirq_prio(base);
 	}
 	set_curr_timer(base, NULL);
 	spin_unlock_irq(&base->lock);



^ permalink raw reply

* [PATCH] UML - TLS fixlets
From: Jeff Dike @ 2006-04-03 15:07 UTC (permalink / raw)
  To: torvalds; +Cc: Blaisorblade, linux-kernel, user-mode-linux-devel

Two small TLS fixes -

arch/um/os-Linux/sys-i386/tls.c uses errno and -E* so it should include 
    errno.h
__setup_host_supports_tls returns 1, but as an initcall, it should return 0

Signed-off-by: Jeff Dike <jdike@addtoit.com>

Index: linux-2.6.16/arch/um/os-Linux/sys-i386/tls.c
===================================================================
--- linux-2.6.16.orig/arch/um/os-Linux/sys-i386/tls.c	2006-04-03 09:39:23.000000000 -0400
+++ linux-2.6.16/arch/um/os-Linux/sys-i386/tls.c	2006-04-03 09:39:42.000000000 -0400
@@ -1,3 +1,4 @@
+#include <errno.h>
 #include <linux/unistd.h>
 #include "sysdep/tls.h"
 #include "user_util.h"
Index: linux-2.6.16/arch/um/sys-i386/tls.c
===================================================================
--- linux-2.6.16.orig/arch/um/sys-i386/tls.c	2006-04-03 09:39:15.000000000 -0400
+++ linux-2.6.16/arch/um/sys-i386/tls.c	2006-04-03 09:39:43.000000000 -0400
@@ -378,7 +378,7 @@ static int __init __setup_host_supports_
 	} else
 		printk(KERN_ERR "  Host TLS support NOT detected! "
 				"TLS support inside UML will not work\n");
-	return 1;
+	return 0;
 }
 
 __initcall(__setup_host_supports_tls);

^ permalink raw reply

* [uml-devel] [PATCH] UML - TLS fixlets
From: Jeff Dike @ 2006-04-03 15:07 UTC (permalink / raw)
  To: torvalds; +Cc: Blaisorblade, linux-kernel, user-mode-linux-devel

Two small TLS fixes -

arch/um/os-Linux/sys-i386/tls.c uses errno and -E* so it should include 
    errno.h
__setup_host_supports_tls returns 1, but as an initcall, it should return 0

Signed-off-by: Jeff Dike <jdike@addtoit.com>

Index: linux-2.6.16/arch/um/os-Linux/sys-i386/tls.c
===================================================================
--- linux-2.6.16.orig/arch/um/os-Linux/sys-i386/tls.c	2006-04-03 09:39:23.000000000 -0400
+++ linux-2.6.16/arch/um/os-Linux/sys-i386/tls.c	2006-04-03 09:39:42.000000000 -0400
@@ -1,3 +1,4 @@
+#include <errno.h>
 #include <linux/unistd.h>
 #include "sysdep/tls.h"
 #include "user_util.h"
Index: linux-2.6.16/arch/um/sys-i386/tls.c
===================================================================
--- linux-2.6.16.orig/arch/um/sys-i386/tls.c	2006-04-03 09:39:15.000000000 -0400
+++ linux-2.6.16/arch/um/sys-i386/tls.c	2006-04-03 09:39:43.000000000 -0400
@@ -378,7 +378,7 @@ static int __init __setup_host_supports_
 	} else
 		printk(KERN_ERR "  Host TLS support NOT detected! "
 				"TLS support inside UML will not work\n");
-	return 1;
+	return 0;
 }
 
 __initcall(__setup_host_supports_tls);


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

^ permalink raw reply

* Re: alsa cvs broken
From: Rene Herman @ 2006-04-03 16:05 UTC (permalink / raw)
  To: Jaroslav Kysela; +Cc: Takashi Iwai, James Courtier-Dutton, alsa-devel
In-Reply-To: <Pine.LNX.4.61.0604031458460.9509@tm8103.perex-int.cz>

Jaroslav Kysela wrote:

> I must say that git looks too much "kernel" oriented and sometimes 
> hard-to-use. Mercurial has my sympatics, because it uses Python (on
> other hand, it might imply some performance issues).
> 
> I would start with mercurial and we'll see then.

Mind a vote against mercurial, and for GIT? Not because I think GIT is 
necesarily (and at the moment) better -- I in fact don't know either yet 
in any detail.

GIT is the kernel SCM though and unless it's really significantly worse, 
I believe it's better to simply use it. I've been looking to get into 
ALSA a bit for example, and I'd really not appreciate having to learn 
yet another SCM when I'm going to be making use of GIT for all the other 
kernel stuff anyway.

GIT is also still picking up speed. Keith Packard was even converting X 
CVS for example. Mercurial might be good I guess, but it's also very 
likely going to be one of those "oh no, not yet another" ones, maybe 
even keeping potential developers away.

Rene.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

^ permalink raw reply

* [PATCH] - add symmetry to para and fully virtualized domain shutdown/reboot
From: Ben Thomas @ 2006-04-03 15:57 UTC (permalink / raw)
  To: xen-devel

[-- Attachment #1: Type: text/plain, Size: 2383 bytes --]

Add code to make handling domain poweroff/reboot symmetrical
between paravirtualized and fully virtualized.

A paravirtualized domain uses sched_op to shut down and set the
reason code. This will send a VIRQ_DOM_EXC, which can be
handled in dom0 by control software.  In some ways, this resembles
SIGCHILD/waitpid, and is a reasonable model.

The fully virtualized case has qemu invoke xm directly. This is a
different path than paravirtualized. It also removes
decision and policy making choices from the rest of the control
software and places it within qemu. When any dom0 logic
eventually gets a VIRQ_DOM_EXC, the information about the
domain is gone having been destroyed by xm.

It would be useful if all shutdown/reboot operations were
symmetrical from domain 0's point of view. One approach
would be to redefine sched_op to handle other domains than
the current domain, but this seemed excessive. Another
approach, which is what this patch implements, adds
a DOM0 hypervisor call very similar to the existing
DOM0_DESTROYDOMAIN, called DOM0_SHUTDOWNDOMAIN, which handles
the shutdown and reason -- basically, just like a
paravirtualized system.

Like DOM0_DESTROYDOMAIN, add a xenctrl wrapper, and have qemu
call it.

With this change, both domain types shutdown/reboot using
the same dom0 management logic. All control decisions are
removed from qemu, which now simply handles the request
and reason. At a very high level, the flow is "notify of
shutdown and reason", "send VIRQ_DOM_EXC", process, and
destroy domain.  Paravirtualized and fully-virtualized
domains would differ slightly in the first step of
notification.  Paravirtualized continues to use sched_op,
fully virtualized uses DOM0_SHUTDOWNDOMAIN. The rest
of the steps would be identical in both cases.

Or, back to the opening sentence, make the operations as
symmetrical as possible.

(As a freebie, #if 0 some very verbose logging code in qemu.
  Totally unrelated, but as long as I was there...)

Signed-off-by: Ben Thomas (ben@virtualiron.com)


-- 
------------------------------------------------------------------------
Ben Thomas                                         Virtual Iron Software
bthomas@virtualiron.com                            Tower 1, Floor 2
978-849-1214                                       900 Chelmsford Street
                                                    Lowell, MA 01851

[-- Attachment #2: shutdown.patch --]
[-- Type: text/x-patch, Size: 5608 bytes --]

diff -r 4ad317429111 tools/ioemu/target-i386-dm/helper2.c
--- a/tools/ioemu/target-i386-dm/helper2.c	Sun Apr  2 16:16:53 2006 +0100
+++ b/tools/ioemu/target-i386-dm/helper2.c	Mon Apr  3 11:22:29 2006 -0400
@@ -409,12 +409,20 @@ void
 void
 destroy_hvm_domain(void)
 {
-    extern FILE* logfile;
-    char destroy_cmd[32];
-
-    sprintf(destroy_cmd, "xm destroy %d", domid);
-    if (system(destroy_cmd) == -1)
-        fprintf(logfile, "%s failed.!\n", destroy_cmd);
+  int	xcHandle;
+  int	sts;
+
+  xcHandle = xc_interface_open();
+  if (xcHandle < 0)
+    fprintf(logfile, "Cannot acquire xenctrl handle\n");
+  else {
+    sts = xc_domain_shutdown(xcHandle, domid, SHUTDOWN_poweroff);
+    if (sts != 0)
+      fprintf(logfile, "? xc_domain_shutdown failed to issue poweroff, sts %d\n", sts);
+    else
+      fprintf(logfile, "Issued domain %d poweroff\n", domid);
+    xc_interface_close(xcHandle);
+  }
 }
 
 fd_set wakeup_rfds;
@@ -480,13 +488,24 @@ int main_loop(void)
 
 static void qemu_hvm_reset(void *unused)
 {
-    char cmd[64];
+  int	xcHandle;
+  int	sts;
 
     /* pause domain first, to avoid repeated reboot request*/
     xc_domain_pause(xc_handle, domid);
 
-    sprintf(cmd, "xm shutdown -R %d", domid);
-    system(cmd);
+  xcHandle = xc_interface_open();
+  if (xcHandle < 0)
+    fprintf(logfile, "Cannot acquire xenctrl handle\n");
+  else {
+    sts = xc_domain_shutdown(xcHandle, domid, SHUTDOWN_reboot);
+    if (sts != 0)
+      fprintf(logfile, "? xc_domain_shutdown failed to issue reboot, sts %d\n", sts);
+    else
+      fprintf(logfile, "Issued domain %d reboot\n", domid);
+    xc_interface_close(xcHandle);
+  }
+
 }
 
 CPUState * cpu_init()
diff -r 4ad317429111 tools/ioemu/vl.c
--- a/tools/ioemu/vl.c	Sun Apr  2 16:16:53 2006 +0100
+++ b/tools/ioemu/vl.c	Mon Apr  3 11:22:29 2006 -0400
@@ -2556,8 +2556,10 @@ static int set_mm_mapping(int xc_handle,
         return -1;
     }
 
+#if 0  /* Enable for debugging -- generates many lines in log file */
     for (i = 0; i < nr_pages; i++)
         fprintf(stderr, "set_map result i %x result %lx\n", i, extent_start[i]);
+#endif
 
     return 0;
 }
diff -r 4ad317429111 tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Sun Apr  2 16:16:53 2006 +0100
+++ b/tools/libxc/xc_domain.c	Mon Apr  3 11:22:29 2006 -0400
@@ -55,6 +55,17 @@ int xc_domain_destroy(int xc_handle,
     DECLARE_DOM0_OP;
     op.cmd = DOM0_DESTROYDOMAIN;
     op.u.destroydomain.domain = (domid_t)domid;
+    return do_dom0_op(xc_handle, &op);
+}
+
+int xc_domain_shutdown(int xc_handle,
+                       uint32_t domid,
+		       int reason)
+{
+    DECLARE_DOM0_OP;
+    op.cmd = DOM0_SHUTDOWNDOMAIN;
+    op.u.shutdowndomain.domain = (domid_t)domid;
+    op.u.shutdowndomain.shutdown_reason = reason;
     return do_dom0_op(xc_handle, &op);
 }
 
diff -r 4ad317429111 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Sun Apr  2 16:16:53 2006 +0100
+++ b/tools/libxc/xenctrl.h	Mon Apr  3 11:22:29 2006 -0400
@@ -205,6 +205,21 @@ int xc_domain_unpause(int xc_handle,
  */
 int xc_domain_destroy(int xc_handle, 
                       uint32_t domid);
+		      
+/**
+ * This function will shutdown a domain. This is intended for use in
+ * fully-virtualized domains where this operation is analogous to the
+ * sched_op operations in a paravirtualized domain. The caller is
+ * expected to give the reason for the shutdown.
+ *
+ * @parm xc_handle a handle to an open hypervisor interface
+ * @parm domid the domain id to destroy
+ * @parm reason is the reason (SHUTDOWN_xxx) for the shutdown
+ * @return 0 on success, -1 on failure
+ */
+int xc_domain_shutdown(int xc_handle, 
+                       uint32_t domid,
+       		       int reason);
 
 int xc_vcpu_setaffinity(int xc_handle,
                         uint32_t domid,
diff -r 4ad317429111 xen/common/dom0_ops.c
--- a/xen/common/dom0_ops.c	Sun Apr  2 16:16:53 2006 +0100
+++ b/xen/common/dom0_ops.c	Mon Apr  3 11:22:29 2006 -0400
@@ -682,6 +682,23 @@ long do_dom0_op(GUEST_HANDLE(dom0_op_t) 
     break;
 #endif
 
+    case DOM0_SHUTDOWNDOMAIN:
+    {
+        struct domain *d = find_domain_by_id(op->u.shutdowndomain.domain);
+        ret = -ESRCH;
+        if ( d != NULL )
+        {
+            ret = -EINVAL;
+            if ( d != current->domain )
+            {
+                domain_shutdown(d, op->u.shutdowndomain.shutdown_reason);
+                ret = 0;
+            }
+	    put_domain(d);
+        }
+    }
+    break;
+
     default:
         ret = arch_do_dom0_op(op, u_dom0_op);
         break;
diff -r 4ad317429111 xen/include/public/dom0_ops.h
--- a/xen/include/public/dom0_ops.h	Sun Apr  2 16:16:53 2006 +0100
+++ b/xen/include/public/dom0_ops.h	Mon Apr  3 11:22:29 2006 -0400
@@ -470,6 +470,15 @@ typedef struct dom0_hypercall_init {
     unsigned long mfn;        /* machine frame to be initialised */
 } dom0_hypercall_init_t;
 DEFINE_GUEST_HANDLE(dom0_hypercall_init_t);
+
+#define DOM0_SHUTDOWNDOMAIN     49
+typedef struct dom0_shutdowndomain {
+    /* IN variables. */
+    domid_t domain;           /* domain to be affected */
+    int     shutdown_reason;  /* SHUTDOWN_xxx reason code */
+} dom0_shutdowndomain_t;
+
+DEFINE_GUEST_HANDLE(dom0_shutdowndomain_t);
 
 typedef struct dom0_op {
     uint32_t cmd;
@@ -512,6 +521,7 @@ typedef struct dom0_op {
         struct dom0_irq_permission    irq_permission;
         struct dom0_iomem_permission  iomem_permission;
         struct dom0_hypercall_init    hypercall_init;
+	struct dom0_shutdowndomain    shutdowndomain;
         uint8_t                       pad[128];
     } u;
 } dom0_op_t;

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply

* how to use v4l / em2820 | em2840
From: Rakotomandimby Mihamina @ 2006-04-03 16:00 UTC (permalink / raw)
  To: linux-kernel

Hi,
I just bougth a Pinnacle Dazzle DV90 USB device:
http://www.mwave.com/mwave/skusearch.hmx?SCriteria=3491061&CartID=done&nextloc=
It is known to work on Linux:
http://www.linuxhq.com/kernel/v2.6/15/Documentation/video4linux/CARDLIST.em28xx

The problem... I did not find any documentation about how to use the
module, to acquire some video + audio with this device.
- I should load em2820
- What others modules have I got to load too?
- Then what command line to perform to save the capture to a file?
	( what is the /dev/foo/bar? ....)

I dont use any particular distribution for the moment, but ask to all
the MLs.
Thank you for your help.
The reply-to is set to me first but I will merge all the information
into a tutorial if I get ver it.
-- 
A powerfull GroupWare, CMS, CRM, ECM: CPS (Open Source & GPL).
Opengroupware, SPIP, Plone, PhpBB, JetSpeed... are good: CPS is better.
http://www.cps-project.org for downloads & documentation.


^ permalink raw reply

* RE: accessed/dirty bit handler tuning
From: Luck, Tony @ 2006-04-03 15:57 UTC (permalink / raw)
  To: linux-ia64
In-Reply-To: <44157CF1.5060902@bull.net>

> It is very much curious having so few dirty and i-access traps...

Your data collection code has races (ld8, add, st8 on one cpu can
race with another cpu doing the same).  So you'll undercount whenever
a race happens.

Perhaps you should use per-cpu counters to collect the values, and
then sum for each cpu in the syscall() before reporting to the user?

-Tony

^ permalink raw reply

* Re: [linux-lvm] dmsetup works, but LVM2 fails
From: Alasdair G Kergon @ 2006-04-03 15:56 UTC (permalink / raw)
  To: LVM general discussion and development
In-Reply-To: <m2irpq4rmb.fsf@janus.isnogud.escape.de>

On Mon, Apr 03, 2006 at 05:15:56PM +0200, Urs Thuermann wrote:
> Do you mean by "For now" that this will change?  

A few people have had trouble over this, so I've gone ahead and
added some code to libdevmapper to handle the compatibility.  
It's inefficient, but at least it should work.

Alasdair
-- 
agk@redhat.com

^ permalink raw reply

* Re: [PATCH] unify PFN_* macros
From: Dave Hansen @ 2006-04-03 15:56 UTC (permalink / raw)
  To: Ralf Baechle; +Cc: akpm, linux-kernel
In-Reply-To: <20060403124916.GA14044@linux-mips.org>

On Mon, 2006-04-03 at 13:49 +0100, Ralf Baechle wrote:
> On Thu, Mar 23, 2006 at 08:24:59AM -0800, Dave Hansen wrote:
> 
> > Just about every architecture defines some macros to do operations on
> > pfns.  They're all virtually identical.  This patch consolidates all
> > of them.
> > 
> > One minor glitch is that at least i386 uses them in a very skeletal
> > header file.  To keep away from #include dependency hell, I stuck
> > the new definitions in a new, isolated header.
> > 
> > Of all of the implementations, sh64 is the only one that varied by a
> > bit.  It used some masks to ensure that any sign-extension got
> > ripped away before the arithmetic is done.  This has been posted to
> > that sh64 maintainers and the development list.
> > 
> > Compiles on x86, x86_64, ia64 and ppc64.
> 
> Ehhh...  Looks at this patch I wonder if you actually read the MIPS bits
> before submitting it:
> 
>  o replaces PFN_ALIGN with PAGE_ALIGN

Yeah, that is blatantly wrong.  I have no idea what I was thinking
there.  

>  o replaces the IP27 definition of PFN_ALIGN with a different one.

That was part of the idea :)  Was there something special about that
implementation?

> How about posting such stuff to linux-arch?  No sane person follows l-k.

I was under the impression that linux-arch wasn't the kind of list which
is supposed to posted to by "normal" people.  I was scolded once for
cc'ing it.  If instructed so, I'd be happy to post there in the future.

-- Dave


^ permalink raw reply

* Re: Laptop fan on Acer 4061NWLCi
From: Saurabh Nanda @ 2006-04-03 15:56 UTC (permalink / raw)
  To: Bruno Ducrot; +Cc: linux-acpi
In-Reply-To: <20060403134138.GA13970@poupinou.org>

Hi,

> Yes, only problem is to define _ON and _OFF methods in order to control
> the fan device.  Good luck...

How do I do that? Can you please point me to some examples?

I've got my fan *visible* (doesn't function -- just visible), under
/proc/acpi. What else should I do to get it actually working?

Nandz.
--
http://nandz.blogspot.com
http://foodieforlife.blogspot.com

^ permalink raw reply

* Re: [RFH] xen domain0 failover stuff
From: Stephen C. Tweedie @ 2006-04-03 15:53 UTC (permalink / raw)
  To: Don Zickus; +Cc: Chris Wright, xen-devel
In-Reply-To: <20060331154401.GE4802@redhat.com>

Hi,

On Fri, 2006-03-31 at 10:44 -0500, Don Zickus wrote:

> > CTRL-a CTRL-a CTRL-a m
> > 
> > Typing that should show you what's available, I suspect it's less than
> > the swiotlb is asking for.
> 
> You know I have never been able to get this to work.  It keeps wanting to
> initializing my modem (minicom uses the same CTRL-a interface).  :)  Or
> maybe this is because I am using the redhat version.  

"ttywatch" (it's in fedora-extras) is what I use for serial console
monitoring.  It logs stuff permanently in the background, with proper
log file rotation; but it also lets you connect to the console live, via
a per-port telnet-to-serial relay, when you need it.  And it passes ^A
through just fine.

btw, for FC5 xen builds, it turns out that serial console input (which
is needed for the HV to see the ^A's) doesn't work unless you specify
pnpacpi=off on the kernel boot line.  We need to work out why: I suspect
that the ACPI pnp bios is tweaking the serial lines for mouse probing
and is upsetting the HV console input in the process.

--Stephen

^ permalink raw reply

* [PATCH] kdump proc vmcore size oveflow fix
From: Vivek Goyal @ 2006-04-03 15:55 UTC (permalink / raw)
  To: linux kernel mailing list, Fastboot mailing list
  Cc: Morton Andrew Morton, Ken'ichi Ohmichi



o Couple of /proc/vmcore data structures overflow with 32bit systems having
  memory more than 4G. This patch fixes those.

Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
---

 fs/proc/vmcore.c        |    4 ++--
 include/linux/proc_fs.h |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff -puN include/linux/proc_fs.h~kdump-vmcore-size-overflow-bug-fix include/linux/proc_fs.h
--- linux-2.6.16-mm2-16M/include/linux/proc_fs.h~kdump-vmcore-size-overflow-bug-fix	2006-04-03 10:20:01.000000000 -0400
+++ linux-2.6.16-mm2-16M-root/include/linux/proc_fs.h	2006-04-03 10:20:01.000000000 -0400
@@ -79,7 +79,7 @@ struct kcore_list {
 struct vmcore {
 	struct list_head list;
 	unsigned long long paddr;
-	unsigned long size;
+	unsigned long long size;
 	loff_t offset;
 };
 
diff -puN fs/proc/vmcore.c~kdump-vmcore-size-overflow-bug-fix fs/proc/vmcore.c
--- linux-2.6.16-mm2-16M/fs/proc/vmcore.c~kdump-vmcore-size-overflow-bug-fix	2006-04-03 10:20:01.000000000 -0400
+++ linux-2.6.16-mm2-16M-root/fs/proc/vmcore.c	2006-04-03 10:34:08.000000000 -0400
@@ -103,8 +103,8 @@ static ssize_t read_vmcore(struct file *
 				size_t buflen, loff_t *fpos)
 {
 	ssize_t acc = 0, tmp;
-	size_t tsz, nr_bytes;
-	u64 start;
+	size_t tsz;
+	u64 start, nr_bytes;
 	struct vmcore *curr_m = NULL;
 
 	if (buflen == 0 || *fpos >= vmcore_size)
_

^ permalink raw reply

* Re: Patch for AICA sound support on SEGA Dreamcast
From: Takashi Iwai @ 2006-04-03 15:52 UTC (permalink / raw)
  To: Adrian McMenamin; +Cc: Alsa-devel, linux-sh, Paul Mundt, LKML
In-Reply-To: <1144075522.11511.20.camel@localhost.localdomain>

At Mon, 03 Apr 2006 15:45:22 +0100,
Adrian McMenamin wrote:
> 
> This provides ALSA sound for the Sega Dreamcast. Seems to work well for
> me, but there is a dearth of testers.
> 
> Signed off by Adrian McMenamin (adrian@mcmen.demon.co.uk)

Thanks for the patch.  Some comments are below.

> diff -ruN /home/adrian/alsa-old/alsa-driver/sh/aica.h /home/adrian/alsa-driver/sh/aica.h
> --- /home/adrian/alsa-old/alsa-driver/sh/aica.h	1970-01-01 01:00:00.000000000 +0100
> +++ /home/adrian/alsa-driver/sh/aica.h	2006-04-03 15:40:07.000000000 +0100
> @@ -0,0 +1,79 @@
(snip)
> +typedef struct {
> +	snd_card_t *card;
> +	snd_pcm_substream_t *substream;
> +	int clicks;
> +	int current_period;
> +	struct timer_list timer;
> +	int master_volume;
> +
> +} snd_card_aica_t;

Please avoid use of typedefs as much as possible.
We (finally :-) got rid of whole typedefs recently from the ALSA core
code.


> +typedef struct aica_channel {
> +	uint32_t cmd;		/* Command ID           */
> +	uint32_t pos;		/* Sample position      */
> +	uint32_t length;	/* Sample length        */
> +	uint32_t freq;		/* Frequency            */
> +	uint32_t vol;		/* Volume 0-255         */
> +	uint32_t pan;		/* Pan 0-255            */
> +	uint32_t sfmt;		/* Sound format         */
> +	uint32_t flags;		/* Bit flags            */
> +} aica_channel_t;

Ditto.


> diff -ruN /home/adrian/alsa-old/alsa-driver/sh/snd_aica.c /home/adrian/alsa-driver/sh/snd_aica.c
> --- /home/adrian/alsa-old/alsa-driver/sh/snd_aica.c	1970-01-01 01:00:00.000000000 +0100
> +++ /home/adrian/alsa-driver/sh/snd_aica.c	2006-04-03 15:40:20.000000000 +0100
> @@ -0,0 +1,802 @@
(snip)
> +
> +static int index = 0;

No need for explicit zero initialization.

> +static char *id = "0";

You should set it to NULL, i.e. don't set value here.

> +static int enable= 1;
> 
> +module_param(index, int, 0444);
> +MODULE_PARM_DESC(index, "Index value for " CARD_NAME " soundcard.");
> +module_param(id, charp, 0444);
> +MODULE_PARM_DESC(id, "ID string for " CARD_NAME " soundcard.");
> +module_param(enable, bool, 0644);
> +MODULE_PARM_DESC(enable, "Enable " CARD_NAME " soundcard.");
> +
> +
> +/* SPU specific functions */
> +
> +inline void spu_write_wait()

Lack of static.  And lack of (void) argument.


> +{
> +	while (1) {
> +		if (!(readl(G2_FIFO) & 0x11))
> +			break;
> +	}

Safer to have a timeout?

> +
> +	return;
> +}
> +
> +
> +
> +static void spu_memset(uint32_t toi, unsigned long what, int length)

The type of second argument should be "void __iomem *" for accessing
readl/writel.


> +{
> +	uint32_t *to = (uint32_t *) (SPU_MEMORY_BASE + toi);
> +	int i;
> +
> +	if (length % 4)
> +		length = (length / 4) + 1;
> +	else
> +		length = length / 4;

Shouldn't be always aligned to 4?  Something like

	snd_assert(length % 4 == 0, return);

> +	spu_write_wait();
> +	for (i = 0; i < length; i++) {
> +		writel(what, to);
> +		to++;
> +		if (i && !(i % 8))
> +			spu_write_wait();
> +	}
> +	return;
> +}
> +
> +static void spu_memload(uint32_t toi, uint8_t * from, int length)

Also "uint8_t __iomem *from" (maybe a "void __iomem *" would be
simpler since you can avoid an explicit cast below).

Also, these lowlevel functions look racy.  Many places call
spu_memload() without a proper lock.

> +{
> +	uint32_t *froml = (uint32_t *) from;
> +	uint32_t *to = (uint32_t *) (SPU_MEMORY_BASE + toi);

Should be "uint32_t __iomem *".

> +	int i, val;
> +	if (length % 4)
> +		length = (length / 4) + 1;
> +	else
> +		length = length / 4;

Similar as spu_memset().

> +	spu_write_wait();
> +	for (i = 0; i < length; i++) {
> +		val = *froml;
> +		writel(val, to);
> +		froml++;
> +		to++;
> +		if (i && !(i % 8))
> +			spu_write_wait();
> +	}
> +	return;
> +
> +}
> +
> +static void spu_disable()

Need (void) for empty argument.

> +{
> +	int i;
> +	uint32_t regval;
> +	spu_write_wait();
> +	regval = readl(ARM_RESET_REGISTER);

readl and writel take void __iomem *.

> +	regval |= 1;
> +	spu_write_wait();
> +	writel(regval, ARM_RESET_REGISTER);
> +	for (i = 0; i < 64; i++) {
> +		spu_write_wait();
> +		regval = readl(SPU_REGISTER_BASE + (i * 0x80));
> +		regval = (regval & ~0x4000) | 0x8000;
> +		spu_write_wait();
> +		writel(regval, SPU_REGISTER_BASE + (i * 0x80));
> +
> +	}
> +
> +}
> +
> +
> +static void spu_enable()

Lack of (void)....  in many others below, too.

> +{
> +	uint32_t regval = readl(ARM_RESET_REGISTER);
> +	regval &= ~1;
> +	spu_write_wait();
> +	writel(regval, ARM_RESET_REGISTER);
> +	return;
> +
> +}
> +
> +
> +/* Halt the sound processor,
> +   clear the memory,
> +   load some default ARM7 code,
> +   and then restart ARM7
> +*/
> +static int spu_init()
> +{
> +
> +	spu_disable();
> +	spu_memset(0, 0, 0x200000 / 4);
> +	*(uint32_t *) SPU_MEMORY_BASE = 0xea000002;

Is it a right code?

> +	spu_enable();
> +	schedule();
> +	return 0;
> +}
> +
> +
> +
> +static aica_channel_t *channel;

Better to assign this to runtime->private_data instead of a static
record.

> +inline static void aica_chn_start()
> +{
> +	spu_write_wait();
> +	writel(AICA_CMD_KICK | AICA_CMD_START,
> +	       (uint32_t *) AICA_CONTROL_POINT);
> +
> +}
> +
> +inline static void aica_chn_halt()
> +{
> +	spu_write_wait();
> +	writel(AICA_CMD_KICK | AICA_CMD_STOP,
> +	       (uint32_t *) AICA_CONTROL_POINT);
> +
> +}
> +
> +
> +/* ALSA code below */
> +
> +static snd_pcm_hardware_t snd_pcm_aica_playback_hw = {

Use struct snd_pcm_hardware, instead.
Refer either ALSA-1.0.11rc4 or 2.6.16 tree.


> +
> +	.info = (SNDRV_PCM_INFO_NONINTERLEAVED),
> +	.formats =
> +	    (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_LE |
> +	     SNDRV_PCM_FMTBIT_IMA_ADPCM),
> +	.rates = SNDRV_PCM_RATE_8000_48000,
> +	.rate_min = 8000,
> +	.rate_max = 48000,
> +	.channels_min = 1,
> +	.channels_max = 2,
> +	.buffer_bytes_max = AICA_BUFFER_SIZE,
> +	.period_bytes_min = AICA_PERIOD_SIZE,
> +	.period_bytes_max = AICA_PERIOD_SIZE,
> +	.periods_min = AICA_PERIOD_NUMBER,
> +	.periods_max = AICA_PERIOD_NUMBER,
> +};
> +
> +/* There is only one sound card on a Dreamcast */
> +static snd_card_aica_t *dreamcastcard = NULL;

Is this static variable really needed?


> +static struct platform_device *pd = NULL;
> +
> +
> +
> +
> +static int stereo_buffer_transfer(snd_pcm_substream_t * substream,

Use struct snd_pcm_substream.

> +				  int buffer_size, int period)
> +{
> +	int transferred;
> +	snd_pcm_runtime_t *runtime;

Use struct snd_pcm_runtime....  in many other places, too.

> +	int period_offset;
> +	period_offset = period;
> +	period_offset %= (AICA_PERIOD_NUMBER / 2);
> +	runtime = substream->runtime;
> +
> +	//snd_printk("period is 0x%X, period_offset is 0x%X, buffer_size is 0x%X\n", period, period_offset, buffer_size);
> +	/* transfer left and then right */
> +	dma_xfer(0,
> +		 runtime->dma_area + (AICA_PERIOD_SIZE * period_offset),
> +		 AICA_CHANNEL0_OFFSET + (AICA_PERIOD_SIZE * period_offset),
> +		 buffer_size / 2, 5);
> +	/* wait for completion */
> +	do {
> +		udelay(5);
> +		transferred = get_dma_residue(0);
> +	}
> +	while (transferred < buffer_size / 2);

Hmm, is this a correct implementation?  It doesf looping in a timer
handler.  Surely it works, but...


> +	dma_xfer(0,
> +		 AICA_BUFFER_SIZE / 2 + runtime->dma_area +
> +		 (AICA_PERIOD_SIZE * period_offset),
> +		 AICA_CHANNEL1_OFFSET + (AICA_PERIOD_SIZE * period_offset),
> +		 buffer_size / 2, 5);
> +	/* have to wait again */
> +	do {
> +		udelay(5);
> +		transferred = get_dma_residue(0);
> +	}
> +	while (transferred < buffer_size / 2);

Ditto.

> +	return 0;
> +}
> +
> +
> +
> +
> +void aica_period_elapsed(unsigned long timer_var)
> +{
> +	int transferred;
> +	int play_period;
> +	snd_pcm_runtime_t *runtime;
> +	runtime = (dreamcastcard->substream)->runtime;

You can use the argument (timer_var) to retrieve an object.

> +
> +	/* Have we played out an additional period? */
> +	play_period =
> +	    frames_to_bytes(runtime,
> +			    readl
> +			    (AICA_CONTROL_CHANNEL_SAMPLE_NUMBER)) /
> +	    AICA_PERIOD_SIZE;
> +	if (play_period == dreamcastcard->current_period) {
> +		dreamcastcard->timer.expires = jiffies + 1;
> +		add_timer(&(dreamcastcard->timer));

I guess you need a proper lock to avoid race here?

> +		return;
> +	}
> +	if (runtime->channels > 1) {
> +		dreamcastcard->current_period = play_period;	/*TO DO: Work out why this doesn't work for 1 channel */
> +
> +		stereo_buffer_transfer(dreamcastcard->substream,
> +				       AICA_PERIOD_SIZE * 2,
> +				       dreamcastcard->clicks);
> +	} else {
> +		dma_xfer(0,
> +			 runtime->dma_area +
> +			 (AICA_PERIOD_SIZE * dreamcastcard->clicks),
> +			 AICA_CHANNEL0_OFFSET +
> +			 (AICA_PERIOD_SIZE * dreamcastcard->clicks),
> +			 AICA_PERIOD_SIZE, 5);
> +		do {
> +			/* Try to fine tune the delay to keep it as short as possible */
> +			udelay(5);
> +			/* get_dma_residue reports residue until completion when it reports total bytes transferred */
> +			transferred = get_dma_residue(0);
> +		}
> +		while (transferred < AICA_PERIOD_SIZE);

Another busy loop in timer callback.

> +	}
> +
> +	snd_pcm_period_elapsed(dreamcastcard->substream);
> +	dreamcastcard->clicks++;
> +	dreamcastcard->clicks %= AICA_PERIOD_NUMBER;
> +	/* reschedule the timer */
> +	dreamcastcard->timer.expires = jiffies + 1;
> +	add_timer(&(dreamcastcard->timer));
> +	return;
> +}
> +
> +static int snd_aicapcm_pcm_open(snd_pcm_substream_t * substream)
> +{
> +	if (!enable) return -ENOENT;

This check is useless.  If needed, do it in module initialization.

> +	channel = kmalloc(sizeof(aica_channel_t), GFP_KERNEL);
> +	if (!channel)
> +		return -ENOMEM;
> +	/* set defaults for channel */
> +	channel->sfmt = SM_8BIT;
> +	channel->cmd = AICA_CMD_START;
> +	channel->vol = dreamcastcard->master_volume;
> +	channel->pan = 0x80;
> +	channel->pos = 0;
> +	channel->flags = 0;	/* default to mono */
> +	snd_pcm_runtime_t *runtime;

Should be in the beginning of the function.

> +	runtime = substream->runtime;
> +	runtime->hw = snd_pcm_aica_playback_hw;
> +	spu_enable();
> +	dreamcastcard->clicks = 0;
> +	dreamcastcard->current_period = 0;
> +	return 0;
> +
> +}
> +
> +static int snd_aicapcm_pcm_close(snd_pcm_substream_t * substream)
> +{
> +	del_timer(&dreamcastcard->timer);
> +	kfree(channel);
> +	spu_disable();
> +	return 0;
> +}
> +
> +static int snd_aicapcm_pcm_hw_free(snd_pcm_substream_t * substream)
> +{
> +	/* Free the DMA buffer */
> +	return snd_pcm_lib_free_pages(substream);
> +}
> +
> +static int snd_aicapcm_pcm_hw_params(snd_pcm_substream_t * substream,
> +				     snd_pcm_hw_params_t * hw_params)
> +{
> +	/* Allocate a DMA buffer using ALSA built-ins */
> +	return
> +	    snd_pcm_lib_malloc_pages(substream,
> +				     params_buffer_bytes(hw_params));
> +}
> +
> +static int snd_aicapcm_pcm_prepare(snd_pcm_substream_t * substream)
> +{
> +
> +	/* Set up the playback */
> +	/* basic settings to test working */
> +	if ((substream->runtime)->format == SNDRV_PCM_FORMAT_S16_LE)
> +		channel->sfmt = SM_16BIT;
> +	channel->freq = substream->runtime->rate;
> +	dreamcastcard->substream = substream;

This one is never unset...

> +	return 0;
> +}
> +
> +
> +static void startup_aica()
> +{
> +	spu_memload(AICA_CHANNEL0_CONTROL_OFFSET, (uint8_t *) channel,
> +		    sizeof(aica_channel_t));
> +	aica_chn_start();
> +	return;
> +}
> +
> +
> +static void spu_begin_dma(snd_pcm_substream_t * substream)
> +{
> +	int buffer_size;
> +	snd_pcm_runtime_t *runtime;
> +	runtime = substream->runtime;
> +	buffer_size = frames_to_bytes(runtime, runtime->buffer_size);
> +	if (runtime->channels == 1)
> +		dma_xfer(0, runtime->dma_area, AICA_CHANNEL0_OFFSET,
> +			 buffer_size, 5);
> +	else {
> +		int transfer_status;
> +		channel->flags |= 0x01;
> +		transfer_status =
> +		    stereo_buffer_transfer(substream, buffer_size, 0);
> +		if (transfer_status != 0)
> +			return;
> +		dreamcastcard->clicks =
> +		    buffer_size / (AICA_PERIOD_SIZE * runtime->channels);
> +	}
> +	startup_aica();
> +	init_timer(&(dreamcastcard->timer));
> +	dreamcastcard->timer.function = aica_period_elapsed;

This is dangerous.  The timer can be running, e.g. when a PCM stream
is replayed.

> +
> +
> +	dreamcastcard->timer.expires = jiffies + 4;

Why 4?

> +	add_timer(&(dreamcastcard->timer));
> +	return;
> +}
> +
> +static int snd_aicapcm_pcm_trigger(snd_pcm_substream_t * substream,
> +				   int cmd)
> +{
> +
> +	switch (cmd) {
> +	case SNDRV_PCM_TRIGGER_START:
> +		spu_begin_dma(substream);
> +		break;
> +	case SNDRV_PCM_TRIGGER_STOP:
> +		aica_chn_halt();

Isn't better to stop the timer here?

> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +
> +
> +	return 0;
> +}
> +
> +static snd_pcm_uframes_t snd_aicapcm_pcm_pointer(snd_pcm_substream_t *
> +						 substream)
> +{
> +	return readl(AICA_CONTROL_CHANNEL_SAMPLE_NUMBER);
> +
> +}
> +
> +
> +static snd_pcm_ops_t snd_aicapcm_playback_ops = {
> +	.open = snd_aicapcm_pcm_open,
> +	.close = snd_aicapcm_pcm_close,
> +	.ioctl = snd_pcm_lib_ioctl,
> +	.hw_params = snd_aicapcm_pcm_hw_params,
> +	.hw_free = snd_aicapcm_pcm_hw_free,
> +	.prepare = snd_aicapcm_pcm_prepare,
> +	.trigger = snd_aicapcm_pcm_trigger,
> +	.pointer = snd_aicapcm_pcm_pointer,
> +};
> +
> +
> +static int snd_aicapcm_free(snd_card_aica_t * dreamcastcard)
> +{
> +	release_mem_region(ARM_RESET_REGISTER, 0x4);
> +	release_mem_region(SPU_MEMORY_BASE, 0x200000);
> +	return 0;
> +}
> +
> +/*	Set up the PCM playback device
> +	card is pointer to the overall AICA device
> +	pcm_index is number of PCM instances - 1
> +
> +	TO DO: set up to handle more than one pcm instance
> +*/
> +
> +
> +static int __init snd_aicapcmchip(snd_card_aica_t * dreamcastcard,
> +				  int pcm_index)
> +{
> +	snd_pcm_t *pcm;
> +	int err;
> +
> +	/* Can we lock the memory */
> +
> +	if (request_mem_region(ARM_RESET_REGISTER, 4, "AICA ARM control")
> +	    == NULL)
> +		return -ENOMEM;
> +	if (request_mem_region(SPU_MEMORY_BASE, 0x200000, "AICA Sound RAM")
> +	    == NULL) {
> +		release_mem_region(ARM_RESET_REGISTER, 0x4);
> +		return -ENOMEM;
> +	}
> +
> +	/* AICA has no capture ability */
> +	if ((err =
> +	     snd_pcm_new(dreamcastcard->card, "AICA PCM", pcm_index, 1, 0,
> +			 &pcm)) < 0)
> +		return err;
> +	pcm->private_data = dreamcastcard;
> +	dreamcastcard->card->private_data = pcm;

What the purpose of this assignment?

> +	strcpy(pcm->name, "AICA PCM");
> +
> +	snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK,
> +			&snd_aicapcm_playback_ops);
> +
> +	/* Allocate the DMA buffers */
> +	err =
> +	    snd_pcm_lib_preallocate_pages_for_all(pcm,
> +						  SNDRV_DMA_TYPE_CONTINUOUS,
> +						  snd_dma_continuous_data
> +						  (GFP_KERNEL),
> +						  AICA_BUFFER_SIZE,
> +						  AICA_BUFFER_SIZE);
> +
> +	return err;
> +}
> +
> +/* Mixer controls */
> +static int aica_pcmswitch_info(snd_kcontrol_t * kcontrol,
> +			       snd_ctl_elem_info_t * uinfo)
> +{
> +	uinfo->type = SNDRV_CTL_ELEM_TYPE_BOOLEAN;
> +	uinfo->count = 1;
> +	uinfo->value.integer.min = 0;
> +	uinfo->value.integer.max = 1;
> +	return 0;
> +}
> +
> +static int aica_pcmswitch_get(snd_kcontrol_t * kcontrol,
> +			      snd_ctl_elem_value_t * ucontrol)
> +{
> +	ucontrol->value.integer.value[0] = 1;	/* TO DO: Fix me */
> +	return 0;
> +}
> +
> +static int aica_pcmswitch_put(snd_kcontrol_t * kcontrol,
> +			      snd_ctl_elem_value_t * ucontrol)
> +{
> +	if (ucontrol->value.integer.value[0] == 1)
> +		return 0;	/* TO DO: Fix me */
> +	else
> +		aica_chn_halt();
> +	return 0;
> +}

I guess this doesn't work (to reenable the DMA)?


> +static int aica_pcmvolume_info(snd_kcontrol_t * kcontrol,
> +			       snd_ctl_elem_info_t * uinfo)
> +{
> +
> +	uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
> +	uinfo->count = 1;
> +	uinfo->value.integer.min = 0;
> +	uinfo->value.integer.max = 0xFF;
> +
> +	return 0;
> +}
> +
> +static int aica_pcmvolume_get(snd_kcontrol_t * kcontrol,
> +			      snd_ctl_elem_value_t * ucontrol)
> +{
> +	if (!channel)
> +		return -ETXTBSY;	/* we've not yet been set up */
> +	ucontrol->value.integer.value[0] = channel->vol;
> +	return 0;
> +}
> +
> +static int aica_pcmvolume_put(snd_kcontrol_t * kcontrol,
> +			      snd_ctl_elem_value_t * ucontrol)
> +{
> +	if (!channel) {
> +		snd_printk("No channel yet\n");
> +		return -ETXTBSY;	/* too soon */
> +	}
> +
> +	else if (channel->vol == ucontrol->value.integer.value[0])
> +		return 0;
> +
> +	else {
> +		channel->vol = ucontrol->value.integer.value[0];
> +		dreamcastcard->master_volume = ucontrol->value.integer.value[0];
> +		spu_memload(AICA_CHANNEL0_CONTROL_OFFSET,
> +			    (uint8_t *) channel, sizeof(aica_channel_t));
> +	}
> +	return 1;
> +}
> +
> +static snd_kcontrol_new_t snd_aica_masterswitch_control __devinitdata = {
> +	.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
> +	.name = "Playback Switch",

Should be "Master Playback Switch".

> +	.info = aica_pcmswitch_info,
> +	.get = aica_pcmswitch_get,
> +	.put = aica_pcmswitch_put
> +};

... But why do you need two different switches for the very same
thing? 

> +static snd_kcontrol_new_t snd_aica_pcmswitch_control __devinitdata = {
> +	.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
> +	.name = "PCM Playback Switch",
> +	.index = 0,
> +	.info = aica_pcmswitch_info,
> +	.get = aica_pcmswitch_get,
> +	.put = aica_pcmswitch_put
> +};
> +
> +
> +static snd_kcontrol_new_t snd_aica_mastervolume_control __devinitdata = {
> +	.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
> +	.name = "Playback Volume",

Should be "Master Playback Volume".

> +	.info = aica_pcmvolume_info,
> +	.get = aica_pcmvolume_get,
> +	.put = aica_pcmvolume_put
> +};
> +
> +static snd_kcontrol_new_t snd_aica_pcmvolume_control __devinitdata = {
> +	.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
> +	.name = "PCM Playback Volume",
> +	.index = 0,
> +	.info = aica_pcmvolume_info,
> +	.get = aica_pcmvolume_get,
> +	.put = aica_pcmvolume_put
> +};

... And again two mixer elements for the very same volume control.


> +
> +
> +static struct device_driver aica_driver = {
> +	.name = "AICA",
> +	.bus = &platform_bus_type,
> +};
> +
> +
> +/* Fill up the members of the embedded device structure */
> +
> +static void populate_dreamcastaicadev(struct device *dev)
> +{
> +	dev->bus = &platform_bus_type;
> +	dev->driver = &aica_driver;
> +	driver_register(dev->driver);
> +	device_bind_driver(dev);
> +}

Looks not right for the recent platform_device...
You can do it better in platform_driver.probe and remove callbacks.


> +static int load_aica_firmware()
> +{
> +	int err;
> +	err = 0;
> +	spu_init();
> +	const struct firmware *fw_entry;
> +	err = request_firmware(&fw_entry, "aica_firmware.bin", &pd->dev);
> +	if (err)
> +		return err;
> +	/* write firware into memory */
> +	spu_disable();
> +	spu_memload(0, fw_entry->data, fw_entry->size);
> +	spu_enable();
> +	release_firmware(fw_entry);
> +	return err;
> +}
> +
> +static int __devinit add_aicamixer_controls()
> +{
> +	int err;
> +	err = snd_ctl_add
> +	     (dreamcastcard->card,
> +	      snd_ctl_new1(&snd_aica_pcmvolume_control,
> +			   dreamcastcard));
> +	     if (err < 0){
> +		snd_printk("pcmvolume failed\n");
> +		return err;
> +	     }
> +	    
> +	    err= snd_ctl_add
> +	     (dreamcastcard->card,
> +	      snd_ctl_new1(&snd_aica_pcmswitch_control,
> +			   dreamcastcard));
> +	     if (err < 0){
> +		snd_printk("pcmswitch failed\n");
> +		return err;
> +	     }
> +
> +	    
> +	    err = snd_ctl_add
> +	     (dreamcastcard->card,
> +	      snd_ctl_new1(&snd_aica_mastervolume_control,
> +			   dreamcastcard));
> +	     if (err < 0){
> +		snd_printk("mastervolume failed\n");
> +		return err;
> +	     }
> +
> +	    
> +	    err = snd_ctl_add
> +	     (dreamcastcard->card,
> +	      snd_ctl_new1(&snd_aica_masterswitch_control,
> +			   dreamcastcard));
> +	     if (err < 0){
> +		snd_printk("masterswitch failed\n");
> +		return err;
> +	     }
> +
> +	    
> +	  
> +	/* succeeded */
> +	return 0;
> +}
> +
> +
> +
> +static int __init aica_init(void)
> +{
> +
> +
> +	int err;
> +	int idx;
> +
> +	/* Are we in a Dreamcast at all? */
> +	if (!mach_is_dreamcast())
> +		return -ENODEV;
> +	dreamcastcard = kmalloc(sizeof(snd_card_aica_t), GFP_KERNEL);
> +	if (!dreamcastcard)
> +		return -ENOMEM;
> +	dreamcastcard->card = NULL;
> +	/* Can only be one real device on a Dreamcast
> +	   but we might have the dummy or some other driver loaded */
> +	for (idx = 0; idx < SNDRV_CARDS; idx++) {
> +		dreamcastcard->card =
> +		    snd_card_new(idx, "AICA", THIS_MODULE, 0);
> +		if (dreamcastcard->card)
> +			break;
> +	}

The code looks odd.  Simply call snd_card_new() once because this driver
supports only one instance anyway.

> +	if (!dreamcastcard->card) {
> +		kfree(dreamcastcard);
> +		return -ENODEV;
> +	}
> +	strcpy(dreamcastcard->card->driver, "snd_card_aica");
> +	strcpy(dreamcastcard->card->shortname, "AICA");
> +	strcpy(dreamcastcard->card->longname,
> +	       "Yamaha AICA Super Intelligent Sound Processor for SEGA Dreamcast");
> +
> +	/* Load the PCM 'chip' */
> +	if ((err = snd_aicapcmchip(dreamcastcard, 0)) < 0)
> +		goto freedreamcast;
> +
> +
> +	pd = platform_device_register_simple(dreamcastcard->card->driver,
> +					     -1, NULL, 0);
> +
> +	if (IS_ERR(pd)) {
> +		err = -ENODEV;
> +		goto freepcm;
> +	}
> +
> +	populate_dreamcastaicadev(&pd->dev);
> +	snd_card_set_dev(dreamcastcard->card, &pd->dev);
> +	/* Register the card with ALSA subsystem */
> +	if ((err = snd_card_register(dreamcastcard->card)) < 0)
> +		goto freepcm;
> +
> +	/* Load the firmware */
> +	err = load_aica_firmware();

The firmware should be loaded before registration of the card
instance.  snd_card_register() will create device files.  It means
that user-space apps are allowed to access the driver.

> +
> +	if (err)
> +		goto freepcm;
> +
> +
> +	/* Add basic controls */
> +	if (add_aicamixer_controls() < 0) goto freepcm;

This should be done before snd_card_register(), too.


> +	snd_printk
> +	    ("ALSA Driver for Yamaha AICA Super Intelligent Sound Processor on slot %d\n",
> +	     idx);
> +
> +	return 0;
> +
> +      freepcm:
> +	snd_aicapcm_free(dreamcastcard);
> +
> +      freedreamcast:
> +	snd_card_free(dreamcastcard->card);
> +
> +	if (pd) {
> +		struct device_driver *drv = (&pd->dev)->driver;
> +		device_release_driver(&pd->dev);
> +		driver_unregister(drv);
> +		platform_device_unregister(pd);
> +		pd = NULL;
> +	}
> +	kfree(dreamcastcard);
> +	return err;
> +
> +
> +}
> +
> +static void __exit aica_exit(void)
> +{
> +
> +	if (likely(dreamcastcard->card)) {

You don't need such an optimization in this place at all.

> +		snd_aicapcm_free(dreamcastcard);
> +		snd_card_free(dreamcastcard->card);
> +		kfree(dreamcastcard);
> +		if (likely(pd)) {
> +			struct device_driver *drv = (&pd->dev)->driver;
> +			device_release_driver(&pd->dev);
> +			driver_unregister(drv);
> +			platform_device_unregister(pd);
> +		}

This should be in remove callback.


Takashi

^ permalink raw reply

* HTTP repo referencing stale heads (can't clone)
From: Daniel Drake @ 2006-04-03 16:01 UTC (permalink / raw)
  To: git

Hi,

I maintain a small git repo. I upload it over ssh (with git-push) to a 
machine where it is distributed over http:

http://dsd.object4.net/git/zd1211.git/

For some reason it is no longer possible to clone this repo over http:

walk 35afe6b3a859242a18812e7485ea8b211e24abaf
walk 93d9a9f469282e1e392c16ce571da4c08805e8bb
error: Couldn't get 
http://dsd.object4.net/git/zd1211.git/refs/heads/softmac-old for 
heads/softmac-old
The requested URL returned error: 404
error: Could not interpret heads/softmac-old as something to pull

"softmac-old" is an old branch, which I have recently deleted. I deleted 
it by removing the .git/refs/heads/softmac-old file, and relying on 
git-prune to clear out old objects.

Even on the server-side, there is no obvious reference to this old head:

$ find -name '*softmac*'
$ grep -R softmac *
(no results for either)

"git-fsck-objects" reports nothing, "git-fsck-objects --full" reports:
dangling commit 7cc423c942975005f96f308186537ad6e7808c2e
dangling commit b36378de6231f1b5100b1517b9c8c243a21090fd

I have tried running git-prune and git-update-server-info, but that 
doesn't help.

Any ideas? I'm still new to git.
I am running git-1.2.4

Thanks,
Daniel

^ permalink raw reply

* [PATCH]mm: Fixing bug in brk
From: Ram Gupta @ 2006-04-03 15:50 UTC (permalink / raw)
  To: akpm; +Cc: linux mailing-list

This patch fixes a bug in sys_brk . The code checks for newbrk with
oldbrk which are page aligned before  making a check for the memory
limit set of data segment. If the memory limit is not page aligned in
that case it bypasses the test for the limit if the memory allocation
is still for the same page. Please apply

Signed-off-by: Ram Gupta ( ram.gupta5@gmail.com)
----------------------------
--- linux-2.6.16/mm/mmap.c.orig 2006-04-03 10:20:18.000000000 +0000
+++ linux-2.6.16/mm/mmap.c      2006-04-03 09:40:00.000000000 +0000
@@ -220,6 +220,16 @@ asmlinkage unsigned long sys_brk(unsigne

        if (brk < mm->end_code)
                goto out;
+
+       /* Check against rlimit here. If this check is not done here & done
+        * later after the test of oldbrk with newbrk then it can escape the
+        * test & let the data segment grow beyond its set limit  in case
+        * when the limit is not page aligned -Ram Gupta */
+
+       rlim = current->signal->rlim[RLIMIT_DATA].rlim_cur;
+       if (rlim < RLIM_INFINITY && brk - mm->start_data > rlim)
+               goto out;
+
        newbrk = PAGE_ALIGN(brk);
        oldbrk = PAGE_ALIGN(mm->brk);
        if (oldbrk == newbrk)
@@ -232,11 +242,6 @@ asmlinkage unsigned long sys_brk(unsigne
                goto out;
        }

-       /* Check against rlimit.. */
-       rlim = current->signal->rlim[RLIMIT_DATA].rlim_cur;
-       if (rlim < RLIM_INFINITY && brk - mm->start_data > rlim)
-               goto out;
-
        /* Check against existing mmap mappings. */
        if (find_vma_intersection(mm, oldbrk, newbrk+PAGE_SIZE))
                goto out;

Thanks
Ram Gupta

^ permalink raw reply

* Re: [Qemu-devel] [PATCH] Add gcc 4.0 support
From: Jim C. Brown @ 2006-04-03 15:50 UTC (permalink / raw)
  To: qemu-devel
In-Reply-To: <4431425E.4040402@gmail.com>

On Mon, Apr 03, 2006 at 05:42:22PM +0200, Dirk Behme wrote:
> Thiemo Seufer wrote:
> >Updated version, note that this is still not suitable for CVS since
> >x86 fails to build with it.
> 
> fyi: for me, arm-softmmu fails as well:
> 

By x86, he probably means x86 hosts, not x86-softmmu

All targets (softmmu and user) would fail on x86 hosts. And possibly other hosts as well.

> Dirk
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

^ permalink raw reply

* RE: accessed/dirty bit handler tuning
From: Luck, Tony @ 2006-04-03 15:49 UTC (permalink / raw)
  To: linux-ia64
In-Reply-To: <44157CF1.5060902@bull.net>

>Unless I am mistaken, there is no purge observed.

The purge cases will be very, very rare.  You either need to be
swapping (so that pages are being stolen out from the process
in the middle of the trap handler), or to construct some special
multi-threaded test (where some threads are re-mapping pieces
of the shared virtual space while other threads are trying to
use those addresses!).  Even in this case the race window is
tiny ... so I'd be surprised to see any benchmark generate more
than a few such purges per hour.

>It is very much curious having so few dirty and i-access traps...

Agreed.  The numbers for dirty/i-access traps are very low (less
than one per invocation of gcc during a kernel build).

>Have you got some good & stressing tests?

Nothing comes to mind that would really stress this code.  Either
you need to make the system swap heavily (boot with mem\x128m, and
then run make -j32, or some such thing ... but some tuning would
be needed to get enough swapping but still make enough progess),
or create some custom multi-threaded test that does mapping &
unmapping (I'm not aware of any real application that does anything
like this ... threads would have to cope with occasional SIGSEGV
if they happened to make an access while the addresses were being
re-mapped).

-Tony

^ permalink raw reply

* jffs2 BUG() on mount
From: Ladislav Michl @ 2006-04-03 15:49 UTC (permalink / raw)
  To: linux-mtd
In-Reply-To: <20060322194939.GA10058@orphique>

(Resend in hope it will not be eaten by spam filter)

On Wed, Mar 22, 2006 at 08:49:39PM +0100, Ladislav Michl wrote:
> With more debugs enabled it ends like this:
> Skipping ino #228 already checked
> Skipping ino #229 already checked
> Skipping ino #270 already checked
> Skipping check of ino #273 with nlink zero
> [lots of skipping check of ino #xxx with nlink zero]
> Skipping check of ino #800 with nlink zero
> Skipping check of ino #801 with nlink zero
> Skipping ino #802 already checked
> Skipping check of ino #803 with nlink zero
> Checked all inodes but still 0x13364c bytes of unchecked space?
> 
> Where checked_ino is 804 and highest_ino 803. ino 802 is already checked
> because userspace requested read meanwhile.

jffs2_scan_inode_node adds also inodes with zero nlink to
unchecked_space, but jffs2_garbage_collect_pass skips them. That
probably leads to above problem. After applying following patch
BUG() is no longer triggered.

Index: fs/jffs2/gc.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/gc.c,v
retrieving revision 1.159
diff -u -r1.159 gc.c
--- fs/jffs2/gc.c	18 Nov 2005 07:27:45 -0000	1.159
+++ fs/jffs2/gc.c	23 Mar 2006 17:39:00 -0000
@@ -211,12 +211,6 @@
 			continue;
 		}
 
-		if (!ic->nlink) {
-			D1(printk(KERN_DEBUG "Skipping check of ino #%d with nlink zero\n",
-				  ic->ino));
-			spin_unlock(&c->inocache_lock);
-			continue;
-		}
 		switch(ic->state) {
 		case INO_STATE_CHECKEDABSENT:
 		case INO_STATE_PRESENT:

I'm not sure what is correct solution. With this change there are lots of
JFFS2 warning: (138) jffs2_get_inode_nodes: Eep. No valid nodes for ino #465.
JFFS2 warning: (138) jffs2_do_read_inode_internal: no data nodes found for ino #465
Returned error for crccheck of ino #465. Expect badness...
warnings. Jffs2 summary feature is disabled. I'd be very gratefull for ideas.

	ladis

^ permalink raw reply

* Re: [openib-general] InfiniBand 2.6.17 merge plans
From: Roland Dreier @ 2006-04-03 15:46 UTC (permalink / raw)
  To: Dan Bar Dov; +Cc: openib-general, linux-kernel
In-Reply-To: <d6944c490604030331s78ba93dap3496b10a08d81326@mail.gmail.com>

    Dan> On the other hand, there are user-space consumers for CMA,
    Dan> such as udapl, so although ISER will attempt only at 2.6.18,
    Dan> maybe it is a good idea to get CMA into 2.6.17

Well, too late now anyway.

But Sean and I agreed that the userspace interface to CMA was not
mature enough to merge for 2.6.17.

 - R.

^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.