On Wed, Nov 23, 2005 at 11:22:18AM -0800, Andrew Morton wrote:
Michal Piotrowski [EMAIL PROTECTED] wrote:
Debug: sleeping function called from invalid context at
include/asm/semaphore.h:123
in_atomic():1, irqs_disabled():0
[c0103be6] dump_stack+0x17/0x19
[c011a0c3]
* Dmitry Torokhov [EMAIL PROTECTED] [2005-11-23 22:26:43 -0500]:
On Wednesday 23 November 2005 21:06, Frank Sorenson wrote:
Andrew Morton wrote:
Marc Koschewski [EMAIL PROTECTED] wrote:
Just booted into 2.6.15-rc2-mm1. The 'mouse problem' (as reported
earlier) still
persists,
Russell King [EMAIL PROTECTED] wrote:
On Wed, Nov 23, 2005 at 10:15:48PM +, Russell King wrote:
Well, I've run 2.6.15-rc2 on what I think was the ARM platform which
exhibited the problem, but it doesn't show up.
The test was merely a did it successfully BOOTP because I can't
get it to
+++ b/drivers/dma/cb_list.h
@@ -0,0 +1,12 @@
+/* Extra macros that build on linux/list.h */
+#ifndef CB_LIST_H
+#define CB_LIST_H
+
+#include linux/list.h
+
+/* Provide some safty to list_add, which I find easy to swap the arguments
to */
+
+#define list_add_entry(pos, head, member)
On Wed, Nov 23, 2005 at 02:44:19PM -0800, David S. Miller wrote:
Please make sure this gets looked at, and at least reviewed.
Jozsef Kadlecsik doesn't recall those patches/changes (even though he's
our Mr. TCP state tracking and is indicated as the author of one of
the two patches.
I also don't
On Thu, Nov 24, 2005 at 03:08:27PM +0100, Harald Welte wrote:
Jozsef Kadlecsik doesn't recall those patches/changes (even though he's
our Mr. TCP state tracking and is indicated as the author of one of
the two patches.
I also don't recall having seen any of those patches before. But that
Hi,
Jeff Garzik wrote:
explanation of this function would be nice. remember to answer how?
and why?, not what?.
Wasn't it the other way around?
Citing linux/Documentation/CodingStyle, section 7 Comments:
Generally, you want your comments to tell WHAT your code does, not HOW.
HOW and WHY
Andi Kleen wrote:
Don't forget that there are benefits of not polluting the cache with the
traffic for the incoming skbs.
Is that a general benefit outside benchmarks? I would expect
most real programs to actually do something with the data
- and that usually involves needing it in
On Thu, Nov 24, 2005 at 05:24:34PM +0200, Avi Kivity wrote:
Andi Kleen wrote:
Don't forget that there are benefits of not polluting the cache with the
traffic for the incoming skbs.
Is that a general benefit outside benchmarks? I would expect
most real programs to actually do
Andi Kleen wrote:
As an example, an NFS server reads some data pages using iSCSI and sends
them using NFS/TCP (or vice versa).
For TX this can be done zero copy using a sendfile like setup.
Yes, or with aio send for anonymous memory.
For RX it may help - but my point was
Just pointing out that it's not clear it will always be a big help.
Agree it should default to in-cache.
This would mean no DMA engine by default.
Clearly there needs to be some heuristic to decide by default. We'll see how
effective it will be in the end.
-Andi
-
To unsubscribe from
This patch fixes graceful stop timeout handling in PPC4xx EMAC driver.
Currently, when we stop TX/RX channels we just do some number of loops
without relying on actual spent time. This has finally bitten me on
one of our systems (heavy network traffic during start up, RX channel
is stopped
Sorry if this email arrived twice on the list.
(This time I subscribed.)
Hi,
I realized that in route.c the inet6_rtm_new_route() function
the inet6_rtm_to_rtmsg() does not take into account the user
supplied flags. This way it seems to be not possible to set the
RTF_DEFAULT flag of a default
13 matches
Mail list logo
