* Re: Respin: [PATCH] mm: limit lowmem_reserve
From: Andrew Morton @ 2006-04-06 3:40 UTC (permalink / raw)
To: Con Kolivas; +Cc: ck, nickpiggin, linux-kernel, linux-mm
In-Reply-To: <200604061258.40487.kernel@kolivas.org>
Con Kolivas <kernel@kolivas.org> wrote:
>
> On Thursday 06 April 2006 12:55, Con Kolivas wrote:
> > On Thursday 06 April 2006 12:43, Andrew Morton wrote:
> > > Con Kolivas <kernel@kolivas.org> wrote:
> > > > It is possible with a low enough lowmem_reserve ratio to make
> > > > zone_watermark_ok fail repeatedly if the lower_zone is small enough.
> > >
> > > Is that actually a problem?
> >
> > Every single call to get_page_from_freelist will call on zone reclaim. It
> > seems a problem to me if every call to __alloc_pages will do that?
>
> every call to __alloc_pages of that zone I mean
>
One would need to check with the NUMA guys. zone_reclaim() has a
(lame-looking) timer in there to prevent it from doing too much work.
That, or I'm missing something. This problem wasn't particularly well
described, sorry.
^ permalink raw reply
* Re: Respin: [PATCH] mm: limit lowmem_reserve
From: Andrew Morton @ 2006-04-06 3:40 UTC (permalink / raw)
To: Con Kolivas; +Cc: ck, nickpiggin, linux-kernel, linux-mm
In-Reply-To: <200604061258.40487.kernel@kolivas.org>
Con Kolivas <kernel@kolivas.org> wrote:
>
> On Thursday 06 April 2006 12:55, Con Kolivas wrote:
> > On Thursday 06 April 2006 12:43, Andrew Morton wrote:
> > > Con Kolivas <kernel@kolivas.org> wrote:
> > > > It is possible with a low enough lowmem_reserve ratio to make
> > > > zone_watermark_ok fail repeatedly if the lower_zone is small enough.
> > >
> > > Is that actually a problem?
> >
> > Every single call to get_page_from_freelist will call on zone reclaim. It
> > seems a problem to me if every call to __alloc_pages will do that?
>
> every call to __alloc_pages of that zone I mean
>
One would need to check with the NUMA guys. zone_reclaim() has a
(lame-looking) timer in there to prevent it from doing too much work.
That, or I'm missing something. This problem wasn't particularly well
described, sorry.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH] [vTPM] interrupt fix
From: Stefan Berger @ 2006-04-06 3:38 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 409 bytes --]
The attached patch fixes a problem that was caused by recent changes to
the xenbus's behavior that cause the .remove function not to be called
anymore during suspend. Due to that the driver allocated one more
interrupt on every suspend/resume cycle.
Otherwise some code reformatting, cleanups and improvements on
allocation and freeing of data structure.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
[-- Attachment #2: tpmfe_interrupt.diff --]
[-- Type: text/x-patch, Size: 7868 bytes --]
Index: root/xen-unstable.hg/linux-2.6-xen-sparse/drivers/xen/tpmfront/tpmfront.c
===================================================================
--- root.orig/xen-unstable.hg/linux-2.6-xen-sparse/drivers/xen/tpmfront/tpmfront.c
+++ root/xen-unstable.hg/linux-2.6-xen-sparse/drivers/xen/tpmfront/tpmfront.c
@@ -65,14 +65,18 @@ static irqreturn_t tpmif_int(int irq,
void *tpm_priv,
struct pt_regs *ptregs);
static void tpmif_rx_action(unsigned long unused);
-static void tpmif_connect(struct tpm_private *tp, domid_t domid);
+static int tpmif_connect(struct xenbus_device *dev,
+ struct tpm_private *tp,
+ domid_t domid);
static DECLARE_TASKLET(tpmif_rx_tasklet, tpmif_rx_action, 0);
-static int tpm_allocate_buffers(struct tpm_private *tp);
+static int tpmif_allocate_tx_buffers(struct tpm_private *tp);
+static void tpmif_free_tx_buffers(struct tpm_private *tp);
static void tpmif_set_connected_state(struct tpm_private *tp,
u8 newstate);
static int tpm_xmit(struct tpm_private *tp,
const u8 * buf, size_t count, int userbuffer,
void *remember);
+static void destroy_tpmring(struct tpm_private *tp);
#define DPRINTK(fmt, args...) \
pr_debug("xen_tpm_fr (%s:%d) " fmt, __FUNCTION__, __LINE__, ##args)
@@ -81,6 +85,8 @@ static int tpm_xmit(struct tpm_private *
#define WPRINTK(fmt, args...) \
printk(KERN_WARNING "xen_tpm_fr: " fmt, ##args)
+#define GRANT_INVALID_REF 0
+
static inline int
tx_buffer_copy(struct tx_buffer *txb, const u8 * src, int len,
@@ -119,6 +125,14 @@ static inline struct tx_buffer *tx_buffe
}
+static inline void tx_buffer_free(struct tx_buffer *txb)
+{
+ if (txb) {
+ free_page((long)txb->data);
+ kfree(txb);
+ }
+}
+
/**************************************************************
Utility function for the tpm_private structure
**************************************************************/
@@ -128,23 +142,29 @@ static inline void tpm_private_init(stru
init_waitqueue_head(&tp->wait_q);
}
+static inline void tpm_private_free(void)
+{
+ tpmif_free_tx_buffers(my_priv);
+ kfree(my_priv);
+ my_priv = NULL;
+}
+
static struct tpm_private *tpm_private_get(void)
{
+ int err;
if (!my_priv) {
my_priv = kzalloc(sizeof(struct tpm_private), GFP_KERNEL);
if (my_priv) {
tpm_private_init(my_priv);
+ err = tpmif_allocate_tx_buffers(my_priv);
+ if (err < 0) {
+ tpm_private_free();
+ }
}
}
return my_priv;
}
-static inline void tpm_private_free(void)
-{
- kfree(my_priv);
- my_priv = NULL;
-}
-
/**************************************************************
The interface to let the tpm plugin register its callback
@@ -233,6 +253,8 @@ static int setup_tpmring(struct xenbus_d
tpmif_tx_interface_t *sring;
int err;
+ tp->ring_ref = GRANT_INVALID_REF;
+
sring = (void *)__get_free_page(GFP_KERNEL);
if (!sring) {
xenbus_dev_fatal(dev, -ENOMEM, "allocating shared ring");
@@ -240,8 +262,6 @@ static int setup_tpmring(struct xenbus_d
}
tp->tx = sring;
- tpm_allocate_buffers(tp);
-
err = xenbus_grant_ring(dev, virt_to_mfn(tp->tx));
if (err < 0) {
free_page((unsigned long)sring);
@@ -251,14 +271,13 @@ static int setup_tpmring(struct xenbus_d
}
tp->ring_ref = err;
- err = xenbus_alloc_evtchn(dev, &tp->evtchn);
+ err = tpmif_connect(dev, tp, dev->otherend_id);
if (err)
goto fail;
- tpmif_connect(tp, dev->otherend_id);
-
return 0;
fail:
+ destroy_tpmring(tp);
return err;
}
@@ -266,14 +285,17 @@ fail:
static void destroy_tpmring(struct tpm_private *tp)
{
tpmif_set_connected_state(tp, 0);
- if (tp->tx != NULL) {
+
+ if (tp->ring_ref != GRANT_INVALID_REF) {
gnttab_end_foreign_access(tp->ring_ref, 0,
(unsigned long)tp->tx);
+ tp->ring_ref = GRANT_INVALID_REF;
tp->tx = NULL;
}
if (tp->irq)
- unbind_from_irqhandler(tp->irq, NULL);
+ unbind_from_irqhandler(tp->irq, tp);
+
tp->evtchn = tp->irq = 0;
}
@@ -377,6 +399,9 @@ static int tpmfront_probe(struct xenbus_
int handle;
struct tpm_private *tp = tpm_private_get();
+ if (!tp)
+ return -ENOMEM;
+
err = xenbus_scanf(XBT_NULL, dev->nodename,
"handle", "%i", &handle);
if (XENBUS_EXIST_ERR(err))
@@ -402,15 +427,14 @@ static int tpmfront_probe(struct xenbus_
static int tpmfront_remove(struct xenbus_device *dev)
{
- struct tpm_private *tp = dev->data;
+ struct tpm_private *tp = (struct tpm_private *)dev->data;
destroy_tpmring(tp);
return 0;
}
-static int
-tpmfront_suspend(struct xenbus_device *dev)
+static int tpmfront_suspend(struct xenbus_device *dev)
{
- struct tpm_private *tp = dev->data;
+ struct tpm_private *tp = (struct tpm_private *)dev->data;
u32 ctr;
/* lock, so no app can send */
@@ -437,29 +461,35 @@ tpmfront_suspend(struct xenbus_device *d
return 0;
}
-static int
-tpmfront_resume(struct xenbus_device *dev)
+static int tpmfront_resume(struct xenbus_device *dev)
{
- struct tpm_private *tp = dev->data;
+ struct tpm_private *tp = (struct tpm_private *)dev->data;
+ destroy_tpmring(tp);
return talk_to_backend(dev, tp);
}
-static void
-tpmif_connect(struct tpm_private *tp, domid_t domid)
+static int tpmif_connect(struct xenbus_device *dev,
+ struct tpm_private *tp,
+ domid_t domid)
{
int err;
tp->backend_id = domid;
+ err = xenbus_alloc_evtchn(dev, &tp->evtchn);
+ if (err)
+ return err;
+
err = bind_evtchn_to_irqhandler(tp->evtchn,
tpmif_int, SA_SAMPLE_RANDOM, "tpmif",
tp);
if (err <= 0) {
WPRINTK("bind_evtchn_to_irqhandler failed (err=%d)\n", err);
- return;
+ return err;
}
tp->irq = err;
+ return 0;
}
static struct xenbus_device_id tpmfront_ids[] = {
@@ -488,19 +518,30 @@ static void __exit exit_tpm_xenbus(void)
xenbus_unregister_driver(&tpmfront);
}
-
-static int
-tpm_allocate_buffers(struct tpm_private *tp)
+static int tpmif_allocate_tx_buffers(struct tpm_private *tp)
{
unsigned int i;
- for (i = 0; i < TPMIF_TX_RING_SIZE; i++)
+ for (i = 0; i < TPMIF_TX_RING_SIZE; i++) {
tp->tx_buffers[i] = tx_buffer_alloc();
- return 1;
+ if (!tp->tx_buffers[i]) {
+ tpmif_free_tx_buffers(tp);
+ return -ENOMEM;
+ }
+ }
+ return 0;
+}
+
+static void tpmif_free_tx_buffers(struct tpm_private *tp)
+{
+ unsigned int i;
+
+ for (i = 0; i < TPMIF_TX_RING_SIZE; i++) {
+ tx_buffer_free(tp->tx_buffers[i]);
+ }
}
-static void
-tpmif_rx_action(unsigned long priv)
+static void tpmif_rx_action(unsigned long priv)
{
struct tpm_private *tp = (struct tpm_private *)priv;
@@ -545,8 +586,7 @@ exit:
}
-static irqreturn_t
-tpmif_int(int irq, void *tpm_priv, struct pt_regs *ptregs)
+static irqreturn_t tpmif_int(int irq, void *tpm_priv, struct pt_regs *ptregs)
{
struct tpm_private *tp = tpm_priv;
unsigned long flags;
@@ -560,10 +600,9 @@ tpmif_int(int irq, void *tpm_priv, struc
}
-static int
-tpm_xmit(struct tpm_private *tp,
- const u8 * buf, size_t count, int isuserbuffer,
- void *remember)
+static int tpm_xmit(struct tpm_private *tp,
+ const u8 * buf, size_t count, int isuserbuffer,
+ void *remember)
{
tpmif_tx_request_t *tx;
TPMIF_RING_IDX i;
@@ -693,8 +732,7 @@ static void tpmif_set_connected_state(st
* =================================================================
*/
-static int __init
-tpmif_init(void)
+static int __init tpmif_init(void)
{
IPRINTK("Initialising the vTPM driver.\n");
if ( gnttab_alloc_grant_references ( TPMIF_TX_RING_SIZE,
@@ -709,8 +747,7 @@ tpmif_init(void)
module_init(tpmif_init);
-static void __exit
-tpmif_exit(void)
+static void __exit tpmif_exit(void)
{
exit_tpm_xenbus();
gnttab_free_grant_references(gref_head);
[-- 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
* [Xenomai-help] question about the latency test running on Blackfin
From: adam li @ 2006-04-06 3:38 UTC (permalink / raw)
To: xenomai
In-Reply-To: <1CFEB358338412458B21FAA0D78FE86D042A2FEE@rennsmail02.eu.thmulti.com>
Hi,
I tried to run the "latency" test on Blackfin 533-STAMP board, in
different modes. Here is the output of the test result:
(I am using xenomai-2.1.0 with default configuration,(adding "timer
benchmark" driver)).
1. # latency -h -t0 -T30
HSH|--param|--samples-|--average--|---stddev--
HSS| min| 29| 9.862| 0.581
HSS| avg| 299964| 11.380| 2.676
HSS| max| 29| 49.759| 5.296
# cat /proc/xenomai/stat
CPU PID MSW CSW PF STAT NAME
0 0 0/0 288239 0 00400080 ROOT
0 47 23/22 145 0 00300082 display
0 48 1/0 220501 0 00300084 sampling
2. # latency -h -t1 -T30
HSH|--param|--samples-|--average--|---stddev--
HSS| min| 29| 6.552| 0.686
HSS| avg| 299985| 8.849| 1.601
HSS| max| 29| 35.379| 6.383
cat /proc/xenomai/stat
CPU PID MSW CSW PF STAT NAME
0 0 0/0 436079 0 00400080 ROOT
0 58 6/5 42 0 00300082 display
0 0 0/0 57685 0 00000084 timerbench
3. # latency -h -t2 -T30
== Sampling period: 100 us
== Test mode: in-kernel timer handler
== All results in microseconds
warming up...
RTT| 00:00:01 (in-kernel timer handler, 100 us period)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
worst
RTD| -5.340| -4.385| 8.064| 0| -5.340|
8.064
RTD| -6.848| -4.359| 8.907| 0| -6.848|
8.907
RTD| -6.443| -4.518| 23.878| 0| -6.848|
23.878
RTD| -5.757| -4.240| 23.377| 0| -6.848|
23.878
RTD| -6.153| -4.144| 24.107| 0| -6.848|
24.107
RTD| -5.446| -4.040| 18.754| 0| -6.848|
24.107
RTD| -7.697| -4.690| 20.319| 0| -7.697|
24.107
HSH|--param|--samples-|--average--|---stddev--
HSS| min| 29| 5.621| 0.820
HSS| avg| 299979| 3.990| 0.774
HSS| max| 29| 15.966| 6.248
And my questions are:
1). Compared the output of Mode 0 (user space task) and Mode 1 (kernel
space task), the average latency of Mode 1 is shorter. In Mode 1, the
"timerbench" thread is running in primary mode, but what makes the
latency in secondary mode longer?
2) From the output of Mode 0, the "MSW" field of "sampling" thread is
always 1/0, does that mean the "sampling" thread will switch to primary
mode and keep stay in primary mode throughout the test?
3) In Mode 2 (timer handler in kernel space), the "lat min" and "lat
avg" is negative, is this correct? If it is correct, why the latency is
much shorter than mode 1(kernel space task)?
And finally a general question:
4) why there is RTDM? What is the design purpose? If I were to write
Realtime device drivers, shall I use RTDM?
Thanks,
-Li Yi
^ permalink raw reply
* wait4/waitpid/waitid oddness
From: Albert Cahalan @ 2006-04-06 3:38 UTC (permalink / raw)
To: linux-kernel
The kernel prohibits:
1. WNOHANG on waitpid/wait4
2. __WALL on waitid
Why? I need both at once.
^ permalink raw reply
* [PATCH] Add documentation for git-imap-send.
From: Mike McCormack @ 2006-04-06 3:32 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 248 bytes --]
Signed-off-by: Mike McCormack <mike@codeweavers.com>
---
Documentation/git-imap-send.txt | 60
+++++++++++++++++++++++++++++++++++++++
1 files changed, 60 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-imap-send.txt
[-- Attachment #2: 39f36da01434f743e36a7b0d6e8f625ad7785b2b.diff --]
[-- Type: text/x-patch, Size: 1350 bytes --]
39f36da01434f743e36a7b0d6e8f625ad7785b2b
diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt
new file mode 100644
index 0000000..cfc0d88
--- /dev/null
+++ b/Documentation/git-imap-send.txt
@@ -0,0 +1,60 @@
+git-imap-send(1)
+================
+
+NAME
+----
+git-imap-send - Dump a mailbox from stdin into an imap folder
+
+
+SYNOPSIS
+--------
+'git-imap-send'
+
+
+DESCRIPTION
+-----------
+This command uploads a mailbox generated with git-format-patch
+into an imap drafts folder. This allows patches to be sent as
+other email is sent with mail clients that cannot read mailbox
+files directly.
+
+Typical usage is something like:
+
+git-format-patch --signoff --stdout --attach origin | git-imap-send
+
+
+CONFIGURATION
+-------------
+
+git-imap-send requires the following values in the repository
+configuration file (shown with examples):
+
+[imap]
+ Folder = "INBOX.Drafts"
+
+[imap]
+ Tunnel = "ssh -q user@server.com /usr/bin/imapd ./Maildir 2> /dev/null"
+
+[imap]
+ Host = imap.server.com
+ User = bob
+ Password = pwd
+ Port = 143
+
+
+BUGS
+----
+Doesn't handle lines starting with "From " in the message body.
+
+
+Author
+------
+Derived from isync 1.0.1 by Mike McCormack.
+
+Documentation
+--------------
+Documentation by Mike McCormack
+
+GIT
+---
+Part of the gitlink:git[7] suite
^ permalink raw reply related
* Re: [ANNOUNCE][RFC] PlugSched-6.3.2 for 2.6.17-rc1
From: Peter Williams @ 2006-04-06 3:35 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Chris Han, Con Kolivas, William Lee Irwin III, Jake Moilanen,
Paolo Ornati, Ingo Molnar
In-Reply-To: <4431FB72.9030907@bigpond.net.au>
Peter Williams wrote:
> This version updates staircase scheduler to version 15 (thanks Con)
> and includes the latest smpnice patches
>
> A patch for 2.6.17-rc1 is available at:
>
> <http://prdownloads.sourceforge.net/cpuse/plugsched-6.3.2-for-2.6.17-rc1.patch?download>
>
>
> Very Brief Documentation:
>
> You can select a default scheduler at kernel build time. If you wish to
> boot with a scheduler other than the default it can be selected at boot
> time by adding:
>
> cpusched=<scheduler>
>
> to the boot command line where <scheduler> is one of: ingosched,
> ingo_ll, nicksched, staircase, spa_no_frills, spa_ws, spa_svr, spa_ebs
> or zaphod. If you don't change the default when you build the kernel
> the default scheduler will be ingosched (which is the normal scheduler).
>
> The scheduler in force on a running system can be determined by the
> contents of:
>
> /proc/scheduler
>
> Control parameters for the scheduler can be read/set via files in:
>
> /sys/cpusched/<scheduler>/
Now available for 2.6.17-rc1-mm1 at:
<http://prdownloads.sourceforge.net/cpuse/plugsched-6.3.2-for-2.6.17-rc1-mm1.patch?download>
Peter
--
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
^ permalink raw reply
* Re: [uml-devel] Re: [PATCH 12/16] UML - Memory hotplug
From: Andrew Morton @ 2006-04-06 3:33 UTC (permalink / raw)
To: jdike, phillips, linux-kernel, user-mode-linux-devel
In-Reply-To: <20060405203233.5fb222ae.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> wrote:
>
> I'll make that change.
uh, no I won't. Am missing changelog, Subject: and Signed-off-by:. Please
send the final patch when it's cooked.
^ permalink raw reply
* Re: [uml-devel] Re: [PATCH 12/16] UML - Memory hotplug
From: Andrew Morton @ 2006-04-06 3:33 UTC (permalink / raw)
To: jdike, phillips, linux-kernel, user-mode-linux-devel
In-Reply-To: <20060405203233.5fb222ae.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> wrote:
>
> I'll make that change.
uh, no I won't. Am missing changelog, Subject: and Signed-off-by:. Please
send the final patch when it's cooked.
-------------------------------------------------------
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: help? converting to single global prio_array in scheduler, ran into snag
From: Darren Hart @ 2006-04-06 3:34 UTC (permalink / raw)
To: Christopher Friesen; +Cc: linux-kernel
In-Reply-To: <4433FCF5.7080604@nortel.com>
On Wednesday 05 April 2006 10:23, you wrote:
> I should clarify that CKRM is currently disabled--I'm trying to get the
> vanilla scheduler working first before changing the CKRM stuff to use
> per-class prio arrays rather than per-class per-cpu ones.
>
First thing that comes to mind, did you look for every place that accesses the
arrays via the rq->lock and make it use the new global array_lock? It would
help if you would post your initial patch for review (designating it as RFC,
not intended for inclusion).
(Chris, sorry for the duplicate, forgot to cc the list first time around)
Thanks,
--Darren
^ permalink raw reply
* Re: [uml-devel] Re: [PATCH 12/16] UML - Memory hotplug
From: Andrew Morton @ 2006-04-06 3:32 UTC (permalink / raw)
To: Jeff Dike; +Cc: phillips, linux-kernel, user-mode-linux-devel
In-Reply-To: <20060406015636.GE6924@ccure.user-mode-linux.org>
Jeff Dike <jdike@addtoit.com> wrote:
>
> + /* 0 means don't wait (like GFP_ATOMIC) and
> + * don't dip into emergency pools (unlike
> + * GFP_ATOMIC).
> + */
> + new = kmalloc(sizeof(*new), 0);
What we've done in the past here is to use (GFP_ATOMIC & ~__GFP_HIGH). It
amounts to the same thing, but it carries some semantic meaning: "whatever
GFP_ATOMIC measn, only don't dip into page reserves".
Plus it future-safes us against changes in GFP_ATOMIC.
I'll make that change.
^ permalink raw reply
* Re: [uml-devel] Re: [PATCH 12/16] UML - Memory hotplug
From: Andrew Morton @ 2006-04-06 3:32 UTC (permalink / raw)
To: Jeff Dike; +Cc: phillips, linux-kernel, user-mode-linux-devel
In-Reply-To: <20060406015636.GE6924@ccure.user-mode-linux.org>
Jeff Dike <jdike@addtoit.com> wrote:
>
> + /* 0 means don't wait (like GFP_ATOMIC) and
> + * don't dip into emergency pools (unlike
> + * GFP_ATOMIC).
> + */
> + new = kmalloc(sizeof(*new), 0);
What we've done in the past here is to use (GFP_ATOMIC & ~__GFP_HIGH). It
amounts to the same thing, but it carries some semantic meaning: "whatever
GFP_ATOMIC measn, only don't dip into page reserves".
Plus it future-safes us against changes in GFP_ATOMIC.
I'll make that change.
-------------------------------------------------------
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
* libnetfilter_queue conditions required to rewrite packets...
From: Mike Auty @ 2006-04-06 3:25 UTC (permalink / raw)
To: netfilter
Hi,
I appologize if this is a bit of a daft question, but looking
through all the documentation I've managed to locate it's never made
explicit, and the list archives are rather difficult to use when looking
for specific information.
I'm trying to make use of the libnetfilter_queue module to
intelligently mangle certain packets on their way through certain points
in iptables. I think I've got all the code working correctly, and I
believe I'm modifying the packet and using a pointer to the modified
packet in the nfq_set_verdict call with the new packet length, however
from all the tests I've run, the original packet is continuing on, and
the new payload seems to be ignored. Are there special conditions under
which packet modification will work, or should it work under all
circumstances?
I've read several things which might help narrow the problem. In
one example (for libipq as it turns out), they have a test so that
rewriting only happens if the packet's come in from hook 0 (which is
PREROUTING). Does this mean that packet modification can only be done
in certain chains (for example, PREROUTING and OUTPUT only)? Must the
NFQUEUE target be in the mangle table rather than the filter table to
perform payload rewriting? I've tried both and I still seem not to be
sending out the modified data. I'd also read somewhere that the kernel
might silently ignore packets if their checksums had not been calculated
correctly. Does this mean invalid packets can't be sent using this
method? Would nfq_set_verdict fail if that were the case? Finally if
the packet contents can be modified no matter where the hook is, does
anyone have any ideas how I could further debug the problem? Last thing
I know is I'm passing the right data to the nfq_set_verdict call and I'm
getting back a positive response, but the data received always appears
to be the original data sent. Is there someway to track what's going on
further inside the netlink?
Any light anyone can shed on this would be greatly appreciated.
Thanks very much...
Mike 5:)
^ permalink raw reply
* Re: Issues with uli526x networking module
From: Nigel Cunningham @ 2006-04-06 3:24 UTC (permalink / raw)
To: Prakash Punnoor; +Cc: linux-kernel, jgarzik
In-Reply-To: <200604041615.10749.prakash@punnoor.de>
[-- Attachment #1: Type: text/plain, Size: 1531 bytes --]
Hi.
On Wednesday 05 April 2006 00:15, Prakash Punnoor wrote:
> Am Dienstag März 28 2006 23:47 schrieb Nigel Cunningham:
> > Hi.
> >
> > On Wednesday 29 March 2006 03:30, Prakash Punnoor wrote:
> > > Hi, I am just wondering whether you found out what the issue is with
> > > the link problem. If you have some patch ready (even if it is hackish)
> > > I would be happy to use it.
> > >
> > > Anyways, I know you are busy with swsusp2. ;-)
> > >
> > > Cheers,
> >
> > Yes, I do have a patch. It is hackish at the moment because as you've
> > rightly guessed, I haven't gotten around to finishing it. It also doesn't
> > work perfectly - I sometimes need to rmmod and insmod after booting a new
> > kernel to get the link to come up. But, apart from that, it works fine.
>
> Thx for sharing it. Unfortunately it doesn't help me. (I am not using
> suspend or anything on that machine as it is supposed to be running 24/7.)
> After pulling out the LAN cable and putting it back in. network is dead.
> The driver (even unpatched) sees the cable is back in, but obviously
> wrongly
> reinitializes(?) the nic: Ie, kernel says after pluggin cable back in:
>
> uli526x: eth0 NIC Link is Up 100 Mbps Full duplex
>
> but network is dead.
>
> I have to do:
>
> ifconfig eth0 down
> modprobe -r uli526x
> modprobe uli526x
> ifconfig eth0 up
> dhclient
>
> And then it works again.
Yes, this is what I was describing too. I need to learn more about how the
link control works.
Regards,
Nigel
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RT task scheduling
From: Darren Hart @ 2006-04-06 3:25 UTC (permalink / raw)
To: linux-kernel
Cc: Ingo Molnar, Thomas Gleixner, Stultz, John, Peter Williams,
Siddha, Suresh B, Nick Piggin
My last mail specifically addresses preempt-rt, but I'd like to know people's
thoughts regarding this issue in the mainline kernel. Please see my previous
post "realtime-preempt scheduling - rt_overload behavior" for a testcase that
produces unpredictable scheduling results.
Part of the issue here is to define what we consider "correct behavior" for
SCHED_FIFO realtime tasks. Do we (A) need to strive for "strict realtime
priority scheduling" where the NR_CPUS highest priority runnable SCHED_FIFO
tasks are _always_ running? Or do we (B) take the best effort approach with
an upper limit RT priority imbalances, where an imbalance may occur (say at
wakeup or exit) but will be remedied within 1 tick. The smpnice patches
improve load balancing, but don't provide (A).
More details in the previous mail...
Thanks,
--Darren
^ permalink raw reply
* 32-on-64 (x86-64) siginfo corruption
From: Albert Cahalan @ 2006-04-06 3:20 UTC (permalink / raw)
To: ak, ak, linux-kernel
The situation: 32-bit debugger, 32-bit child, 64-bit kernel
The debugger sends an RT signal to the child. (to stop it, with
a queue and siginfo so that non-debugger signals don't get lost)
To do this, the debugger uses tgkill().
Later, the debugger checks the child's siginfo_t before discarding
it. This is to be sure that the child didn't get the RT signal from
some other source. The debugger fills a siginfo_t with 0xff, then
fetches siginfo data via ptrace. The data is corrupt:
FIELD 32-ON-64 NORMAL
si_pid -1 getpid()
si_uid getpid() getuid()
The "getpid" and "getuid" above are done in the debugger, not in
the child. The si_code values are SI_TKILL.
Probably the other ports with 32-on-64 support ought to verify
that this stuff works right.
^ permalink raw reply
* Is teardown_irq still required?
From: Tian, Kevin @ 2006-04-06 3:14 UTC (permalink / raw)
To: ian.pratt, Keir Fraser, xen-devel
Hi, Ian/Keir,
Just noted the change to kernel/irq/manage.c by adding
teardown_irq which is also part of the patch sets you proposed to linux
kernel long time ago. However currently no one seems to invoke
teardown_irq directly based on the purpose for adding it.
Does the assumption still hold true that some static irqaction
may be
freed by this way? Or previous requirement already disappears today?
Now all the virtual drivers finally fall down to request_irq which
matches
free_irq. Only instances to call setup_irq are native linux drivers,
where
free_irq is not required for those architecture specific static irq
number.
Maybe this change can be removed now?
Thanks,
Kevin
^ permalink raw reply
* realtime-preempt scheduling - rt_overload behavior
From: Darren Hart @ 2006-04-06 3:13 UTC (permalink / raw)
To: linux-kernel; +Cc: Ingo Molnar, Thomas Gleixner, Stultz, John
[-- Attachment #1: Type: text/plain, Size: 1624 bytes --]
I have been experimenting with realtime scheduling and have come across some
unexpected results. When running the attached testcase it's apparent that
lower priority SCHED_FIFO threads are running while higher priority
SCHED_FIFO threads sit runnable on another CPU's run_queue.
First, what are the expectations for the realtime scheduler? Are we trying
for "system wide strict realtime priority scheduling", should we consider the
above scenario a bug?
From what I could gather reading sched.c (2.6.16-rt11), the scheduler will
increment rt_overload anytime a run_queue has 2 RT tasks on it - so
rt_overload is >0 anytime NR_CPUS+1 RT tasks are runnable on the system.
schedule() calls pull_rt_tasks() anytime it runs and sees that rt_overload is
> 0 and pulls the highest priority runnable rt task off each run_queue and
places them on its CPU's run_queue. I also see that we call
smp_send_reschedule() (or similar) when an RT task is waking up or being
bumped off the run_queue. So clearly we are trying to prevent the above
scenario from happening.
I'd appreciate your thoughts on this. Any comments on the test case are also
welcome. As I understand it, sched_yield() will place a SCHED_FIFO task back
on the active array, and if it is still the highest prio RT task it will get
rescheduled immediately (which it likely is since a higher priority task
should have preempted it when it became runnable).
(the testcase "fails" more often on 4way and bigger machines, with around
2xCPUS threads per team. './sched_football 8 10' for example.)
Thanks,
--Darren
[-- Attachment #2: sched_football.c --]
[-- Type: text/x-csrc, Size: 4418 bytes --]
/* Threaded Football - by John Stultz <johnstul@us.ibm.com>
*
* This is a scheduler test that uses a football analogy.
* The premise is that we want to make sure that lower priority threads
* (the offensive team) do not preempt higher priority threads (the
* defensive team). The offense is trying to increment the balls position,
* while the defense is trying to block that from happening.
* And the ref (highest priority thread) will blow the wistle if the
* ball moves. Finally, we have crazy fans (higer prority) that try to
* distract the defense by occasionally running onto the field.
*
* PS: I really don't like football that much, it just seemed to fit.
*
* 2006-03-16 Reduced verbosity, non binary failure reporting, removal of
* crazy_fans thread, added game_length argument by Darren Hart.
*/
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <time.h>
#include <string.h>
#include <pthread.h>
#include <sched.h>
#include <errno.h>
#include <sys/syscall.h>
#define MAXTHREADS 256
#define DEF_GAME_LENGTH 5
/* Here's the position of the ball */
volatile int the_ball;
/* Game status */
volatile int game_over;
/* Keep track of who's on the field */
volatile int offense_count;
volatile int defense_count;
volatile int crazyfan_count;
/* simple mutex for our atomic increments */
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
#define min(x,y) (x < y ? x: y)
/* This is the defensive team. They're trying to block the offense */
void *thread_defense(void* arg)
{
pthread_mutex_lock(&mutex);
defense_count++;
pthread_mutex_unlock(&mutex);
/*keep the ball from being moved */
while (!game_over) {
sched_yield(); /* let other defenders run */
}
}
/* This is the offensive team. They're trying to move the ball */
void *thread_offense(void* arg)
{
pthread_mutex_lock(&mutex);
offense_count++;
pthread_mutex_unlock(&mutex);
while (!game_over) {
the_ball++; /* move the ball ahead one yard */
sched_yield(); /* let other offensive players run */
}
}
void referee(int game_length)
{
struct timeval start, now;
printf("Game On (%d seconds)!\n", game_length);
gettimeofday(&start, 0);
now = start;
the_ball = 0;
/* Watch the game */
while ((now.tv_sec - start.tv_sec) < game_length) {
sleep(1);
gettimeofday(&now, 0);
}
/* Blow the whistle */
printf("Game Over!\n");
printf("Final ball position: %d\n", the_ball);
game_over = 1;
}
void create_thread(pthread_t *thread, void*(*func)(void*), int prio)
{
pthread_attr_t attr;
struct sched_param param;
param.sched_priority = sched_get_priority_min(SCHED_FIFO) + prio;
pthread_attr_init(&attr);
pthread_attr_setinheritsched (&attr, PTHREAD_EXPLICIT_SCHED);
pthread_attr_setschedparam(&attr, ¶m);
pthread_attr_setschedpolicy(&attr, SCHED_FIFO);
if (pthread_create(thread, &attr, func, (void *)0)) {
perror("pthread_create failed");
}
pthread_attr_destroy(&attr);
}
int main(int argc, char* argv[])
{
struct sched_param param;
int players_per_team, game_length;
int priority;
int thread_count = 0;
pthread_t thread_id[MAXTHREADS];
int i;
if (argc < 2 || argc > 3) {
printf("Usage: %s players_per_team [game_length (seconds)]\n", argv[0]);
exit(1);
}
players_per_team = atoi(argv[1]);
if (argc == 3)
game_length = atoi(argv[2]);
else
game_length = DEF_GAME_LENGTH;
/* We're the ref, so set our priority right */
param.sched_priority = sched_get_priority_min(SCHED_FIFO) + 80;
sched_setscheduler(0, SCHED_FIFO, ¶m);
/* Start the offense */
priority = 15;
printf("Starting %d offense threads at priority %d\n",
players_per_team, priority);
for (i = 0; i < players_per_team; i++)
create_thread(&thread_id[thread_count],
thread_offense, priority);
while (offense_count < players_per_team)
usleep(100);
/* Start the defense */
priority = 30;
printf("Starting %d defense threads at priority %d\n",
players_per_team, priority);
for (i = 0; i < players_per_team; i++)
create_thread(&thread_id[thread_count++],
thread_defense, priority);
while (defense_count < players_per_team)
usleep(100);
/* Ok, everyone is on the field, bring out the ref */
printf("Starting referee thread\n");
referee(game_length);
for (i = 0; i < thread_count; i++) {
usleep(100);
pthread_join(thread_id[i], 0);
}
return 0;
}
^ permalink raw reply
* Re: [ANNOUNCE] udev 089 release
From: Greg KH @ 2006-04-06 3:12 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20060403171123.GA24860@vrfy.org>
On Thu, Apr 06, 2006 at 03:54:17AM +0300, juuso.alasuutari@tamperelainen.org wrote:
> Quoting Scott James Remnant <scott@ubuntu.com>:
>
> > > If you can convince me why we would want to filter out events on the
> > > event generation side instead of doing that on the event handling side.
> > > I'm not sure about the idea of controlling the module load order or the
> > > other weird things that way, but you may may have good reasons I don't
> > > see at the moment.
> > >
> > The principal reason for us at the moment is in the initramfs; in the
> > main system we just plug everything and let the order be damned.
> > Indeed, wherever we've found a situation where a module load order is
> > necessary (I know of three or four I think at the moment) we've decided
> > that the bug is in the driver for requiring that order.
>
> I just wanted to pop in to confirm that network device modules loading in random
> order can be a pain. When interfaces are not always named in the same order,
> things can become more complicated than they should be.
> This can of course be avoided with rules that bind MAC addresses to fixed names,
> but it would be much nicer to have a predictable loading order.
Use MAC addressed to create fixed names if you really care about this.
Otherwise, the loading order is never guaranteed to be the same (pci bus
ids change, usb ids change, etc.)
thanks,
greg k-h
-------------------------------------------------------
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\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: [ANNOUNCE] udev 089 release
From: Scott James Remnant @ 2006-04-06 3:02 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20060403171123.GA24860@vrfy.org>
[-- Attachment #1: Type: text/plain, Size: 650 bytes --]
On Wed, 2006-04-05 at 21:36 +0200, Marco d'Itri wrote:
> On Apr 05, Scott James Remnant <scott@ubuntu.com> wrote:
>
> > In the initramfs, we exercise a little more caution; making sure that we
> > only probe PCI IDE or SCSI controllers first before we move on to
> > probing for USB buses. The reasoning for this is that we don't want
> > someone's fast USB pen drive beating their SATA or SCSI disk to
> > getting /dev/sda1
> Why would this be a bad?
>
root=/dev/sda1 ... "uh, why did it try and mount my iPod as the root
disk?"
(Orthogonal to the "use UUID/Label" argument).
Scott
--
Scott James Remnant
scott@ubuntu.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Respin: [PATCH] mm: limit lowmem_reserve
From: Con Kolivas @ 2006-04-06 2:58 UTC (permalink / raw)
To: ck; +Cc: Andrew Morton, nickpiggin, linux-kernel, linux-mm
In-Reply-To: <200604061255.55055.kernel@kolivas.org>
On Thursday 06 April 2006 12:55, Con Kolivas wrote:
> On Thursday 06 April 2006 12:43, Andrew Morton wrote:
> > Con Kolivas <kernel@kolivas.org> wrote:
> > > It is possible with a low enough lowmem_reserve ratio to make
> > > zone_watermark_ok fail repeatedly if the lower_zone is small enough.
> >
> > Is that actually a problem?
>
> Every single call to get_page_from_freelist will call on zone reclaim. It
> seems a problem to me if every call to __alloc_pages will do that?
every call to __alloc_pages of that zone I mean
Cheers,
Con
^ permalink raw reply
* Re: Respin: [PATCH] mm: limit lowmem_reserve
From: Con Kolivas @ 2006-04-06 2:58 UTC (permalink / raw)
To: ck; +Cc: Andrew Morton, nickpiggin, linux-kernel, linux-mm
In-Reply-To: <200604061255.55055.kernel@kolivas.org>
On Thursday 06 April 2006 12:55, Con Kolivas wrote:
> On Thursday 06 April 2006 12:43, Andrew Morton wrote:
> > Con Kolivas <kernel@kolivas.org> wrote:
> > > It is possible with a low enough lowmem_reserve ratio to make
> > > zone_watermark_ok fail repeatedly if the lower_zone is small enough.
> >
> > Is that actually a problem?
>
> Every single call to get_page_from_freelist will call on zone reclaim. It
> seems a problem to me if every call to __alloc_pages will do that?
every call to __alloc_pages of that zone I mean
Cheers,
Con
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Bonnie++ Burps on XFS
From: Nathan Scott @ 2006-04-06 2:57 UTC (permalink / raw)
To: LKML; +Cc: linux-xfs
In-Reply-To: <20060406023445.GB5806@kurtwerks.com>
On Wed, Apr 05, 2006 at 10:34:45PM -0400, Kurt Wall wrote:
> I've been using bonnie++ off and on for a long time. Suddenly, it has
> started failing when run against an XFS filesystem situated on a SATA
> drive. Here's the output of a run:
[ Please report these things to linux-xfs@oss.sgi.com... ]
> Delete files in sequential order...Bonnie: drastic I/O error (rmdir):
Anything in your system log?
> clear if the problems is XFS, some other piece of the kernel, or
> bonnie++. Neither dmesg nor syslog shows anything amiss. I suppose
> I could strace the run, but I'm not especially eager to deal with
> a multi-gigabyte output file if there is a more focused method to
> isolate the problem.
See if 2.6.16.1 fails too for starters then we'll take it from there.
cheers.
--
Nathan
^ permalink raw reply
* [PATCH] vr41xx: fix plat_irq_dispatch()
From: Yoichi Yuasa @ 2006-04-06 3:07 UTC (permalink / raw)
To: Ralf Baechle; +Cc: yoichi_yuasa, linux-mips
Hi Ralf,
This patch has fixed the wrong conversion of plat_irq_dispatch() for vr41xx.
Please apply.
Yoichi
Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/vr41xx/common/irq.c mips/arch/mips/vr41xx/common/irq.c
--- mips-orig/arch/mips/vr41xx/common/irq.c 2006-04-06 11:26:29.216597750 +0900
+++ mips/arch/mips/vr41xx/common/irq.c 2006-04-06 11:57:42.581675750 +0900
@@ -91,23 +91,16 @@ asmlinkage void plat_irq_dispatch(struct
if (pending & CAUSEF_IP7)
do_IRQ(7, regs);
else if (pending & 0x7800) {
- if (pending & CAUSEF_IP3) {
+ if (pending & CAUSEF_IP3)
irq_dispatch(3, regs);
- return;
- } else if (pending & CAUSEF_IP4) {
+ else if (pending & CAUSEF_IP4)
irq_dispatch(4, regs);
- return;
- } else if (pending & CAUSEF_IP5) {
+ else if (pending & CAUSEF_IP5)
irq_dispatch(5, regs);
- return;
- } else if (pending & CAUSEF_IP6) {
+ else if (pending & CAUSEF_IP6)
irq_dispatch(6, regs);
- return;
- }
- }
-
- if (pending & CAUSEF_IP2)
- do_IRQ(2, regs);
+ } else if (pending & CAUSEF_IP2)
+ irq_dispatch(2, regs);
else if (pending & CAUSEF_IP0)
do_IRQ(0, regs);
else if (pending & CAUSEF_IP1)
^ permalink raw reply
* Re: Respin: [PATCH] mm: limit lowmem_reserve
From: Con Kolivas @ 2006-04-06 2:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, ck, nickpiggin, linux-mm
In-Reply-To: <20060405194344.1915b57a.akpm@osdl.org>
On Thursday 06 April 2006 12:43, Andrew Morton wrote:
> Con Kolivas <kernel@kolivas.org> wrote:
> > It is possible with a low enough lowmem_reserve ratio to make
> > zone_watermark_ok fail repeatedly if the lower_zone is small enough.
>
> Is that actually a problem?
Every single call to get_page_from_freelist will call on zone reclaim. It
seems a problem to me if every call to __alloc_pages will do that?
Cheers,
Con
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.