On Fri, Aug 11, 2006 at 08:45:31AM -0700, Andrew Morton ([EMAIL PROTECTED])
wrote:
+static struct lock_class_key kevent_poll_key;
+
+void kevent_poll_reinit(struct file *file)
+{
+ lockdep_set_class(file-st.lock, kevent_poll_key);
+}
Why is this necessary?
Locks for all storages
On Sat, 12 Aug 2006 12:18:35 +0400
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
On Fri, Aug 11, 2006 at 08:45:31AM -0700, Andrew Morton ([EMAIL PROTECTED])
wrote:
+static struct lock_class_key kevent_poll_key;
+
+void kevent_poll_reinit(struct file *file)
+{
+
On Fri, Aug 11, 2006 at 11:42:50PM -0400, Rik van Riel ([EMAIL PROTECTED])
wrote:
Dropping these non-essential packets makes sure the reserve memory
doesn't get stuck in some random blocked user-space process, hence
you can make progress.
In short:
- every incoming packet needs to be
Enabling PXA DMA for the smc91x on the logicpd pxa270 produces
unacceptable interference with the TFT panel, so disable it. Also
delete the lpd270 versions of the SMC_{in,out}[bl]() macros, as they
aren't used, since the board only supports 16bit accesses.
Signed-off-by: Lennert Buytenhek [EMAIL
Please include the attached patch that adds support for a new PHY to the
sis900 driver. See also Bugzilla 6919.
Signed-off-by: Daniele Venzano [EMAIL PROTECTED]
--
--
Daniele Venzano
Web: http://teg.homeunix.org
diff -urN linux-source-2.6.15/drivers/net/sis900.c
On Sat, Aug 12, 2006 at 10:55:07AM +0200, Lennert Buytenhek wrote:
Enabling PXA DMA for the smc91x on the logicpd pxa270 produces
unacceptable interference with the TFT panel, so disable it.
Doesn't this disable it for all users, though? are there any other
users? should this be changed from a
On Sat, Aug 12, 2006 at 12:27:52PM +0300, Muli Ben-Yehuda wrote:
Enabling PXA DMA for the smc91x on the logicpd pxa270 produces
unacceptable interference with the TFT panel, so disable it.
Doesn't this disable it for all users, though?
Nope. Unfortunately, the line that made that clear
On Sat, Aug 12, 2006 at 11:30:35AM +0200, Lennert Buytenhek wrote:
Nope. Unfortunately, the line that made that clear didn't fall inside
the patch context:
Ah, I see. Thanks.
Cheers,
Muli
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
Andreas Mohr wrote:
Constify largish areas of firmware data in Tigon3 ethernet driver.
ACK
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello!
Makes sense, especially for auto generated handles. I've been listening
to the notifications on a separate socket for this purpose.
That's... complicated. But cool. :-)
It does make sense, the way it has been implemented if at all is
creepy. Even worse, IPv6 is using current-pid,
Hello!
Actually I think the only safe solution is to allocate a separate
socket for multicast messages. In other words, if you want reliable
unicast reception on a socket, don't bind it to a multicast group.
Yes, it was the point of my advocacy of NLM_F_ECHO. :-)
Alexey
-
To unsubscribe
* Alexey Kuznetsov [EMAIL PROTECTED] 2006-08-12 15:03
Actually, it was the idea. If requestor asked NLM_F_ECHO and subscribed
to muticasts, it suppresses double notifications. If it did not ask
NLM_F_ECHO, he is not interested in results, he knows what's going on
without this.
F.e. it was
On Mon, Aug 07, 2006 at 05:29:54PM -0700, Jesse Brandeburg wrote:
On 8/7/06, David Miller [EMAIL PROTECTED] wrote:
From: Christoph Hellwig [EMAIL PROTECTED]
Date: Sat, 5 Aug 2006 15:01:09 +0200
All caller of netdev_alloc_skb need to assign skb-dev shortly
afterwards. Move it into common
On Saturday 12 August 2006 15:39, Jeff Garzik wrote:
Andrew Morton wrote:
It would be good if you could poke around in gdb, work out exactly which
statement it's oopsing at, please.
I'm also interested to know if the problem goes away when you disable
preempt...
That will take some time
Evgeniy Polyakov wrote:
On Sat, Aug 12, 2006 at 11:19:49AM +0200, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
As you described above, memory for each packet must be allocated (either
from SLAB or from reserve), so network needs special allocator in OOM
condition, and that allocator should be
Peter Zijlstra wrote:
Index: linux-2.6/include/linux/gfp.h
===
--- linux-2.6.orig/include/linux/gfp.h 2006-08-12 12:56:06.0 +0200
+++ linux-2.6/include/linux/gfp.h 2006-08-12 12:56:09.0 +0200
@@ -46,6 +46,7 @@
On Sat, Aug 12, 2006 at 10:40:23AM -0400, Rik van Riel ([EMAIL PROTECTED])
wrote:
Evgeniy Polyakov wrote:
On Sat, Aug 12, 2006 at 11:19:49AM +0200, Peter Zijlstra
([EMAIL PROTECTED]) wrote:
As you described above, memory for each packet must be allocated (either
from SLAB or from reserve),
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Evgeniy Polyakov wrote:
On Sat, Aug 12, 2006 at 09:31:42AM -0400, John Richard Moser ([EMAIL
PROTECTED]) wrote:
I'm told now that it uses Jiffies for TCP timestamps. I've had thoughts
on this:
- I figured a random timestamp with random
Evgeniy Polyakov wrote:
On Sat, Aug 12, 2006 at 10:40:23AM -0400, Rik van Riel ([EMAIL PROTECTED])
wrote:
Evgeniy Polyakov wrote:
On Sat, Aug 12, 2006 at 11:19:49AM +0200, Peter Zijlstra
([EMAIL PROTECTED]) wrote:
As you described above, memory for each packet must be allocated (either
from
On Sat, 2006-08-12 at 10:41 -0400, Jeff Garzik wrote:
Peter Zijlstra wrote:
Index: linux-2.6/include/linux/gfp.h
===
--- linux-2.6.orig/include/linux/gfp.h 2006-08-12 12:56:06.0
+0200
+++
On Sat, Aug 12, 2006 at 10:56:31AM -0400, Rik van Riel ([EMAIL PROTECTED])
wrote:
Yep. Socket allocations end up with alloc_skb() which is essentialy the
same as what is being done for receiving path skbs.
If you really want to separate critical from non-critical sockets, it is
much better
On Sat, 2006-08-12 at 19:08 +0400, Evgeniy Polyakov wrote:
One must receive a packet to determine if that packet must be dropped
until tricky hardware with header split capabilities or MMIO copying is
used.
True, that is done, but we then discard this packet at the very first
moment we know
On Sat, August 12, 2006 17:06, Peter Zijlstra said:
On Sat, 2006-08-12 at 10:41 -0400, Jeff Garzik wrote:
Peter Zijlstra wrote:
Index: linux-2.6/include/linux/gfp.h
===
--- linux-2.6.orig/include/linux/gfp.h 2006-08-12
On Sat, Aug 12, 2006 at 04:31:18PM +0200, Rafael J. Wysocki wrote:
On Saturday 12 August 2006 14:28, Andrew Morton wrote:
On Sat, 12 Aug 2006 12:07:42 +0200
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
Hi,
On 2.6.18-rc3-mm2 with hotfixes I get things like the appended one on
Anton Blanchard wrote:
Hi,
--- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea_ethtool.c 1969-12-31
+static void netdev_get_pauseparam(struct net_device *dev,
+ struct ethtool_pauseparam *pauseparam)
+{
+ printk(get pauseparam\n);
+}
There
Anton Blanchard wrote:
--- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea.h 1969-12-31
+extern void exit(int);
Should be able to remove that prototype :)
Anton
Indeed :-) It's gone.
Thomas
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a
On Sat, August 12, 2006 16:14, Peter Zijlstra said:
Hi,
here the latest effort, it includes a whole new trivial allocator with a
horrid name and an almost full rewrite of the deadlock prevention core.
This version does not do anything per device and hence does not depend
on the new
The vendor driver chooses this value based on an ifndef ASIC,
and ASIC is never defined.
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
---
This should go into 2.6.18 as it fixed TX on one of my devices.
zd_chip.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Index:
The vendor driver resets the IFS value every time the channel changes,
to this one.
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
---
zd_chip.c | 11 +++
zd_chip.h |8
2 files changed, 15 insertions(+), 4 deletions(-)
Index:
This patch synchronizes our code to some recent vendor driver modifications.
A new PHY layout is supported, some values are tweaked, and the AL2230 is now
programmed over a new interface which is many times faster.
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
Index:
Tested by Wonka on IRC.
zd1211 chip 157e:3204 v4810 high 00-11-e0 AL7230B_RF pa0 g---
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
---
zd_usb.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Index: linux-2.6/drivers/net/wireless/zd1211rw/zd_usb.c
Tested by lyakh on IRC
zd1211 chip 1740:2000 v4721 high 00-02-6f AL7230B_RF pa0 g---
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
---
zd_usb.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/zd_usb.c b/zd_usb.c
index 044f209..5284357 100644
---
This is needed for my G220F, otherwise it fails to initialize after the
existing firmware upload routine.
The vendor driver actually does more than what I have done here: it
downloads the firmware + boot code, modifies it, and uploads it again
(really messy). I have not copied that part over, as
This patch adds support for another Airoha RF which is present in some
ZD1211 adapters. This RF supports 802.11a as well as 802.11b/g, but 802.11a
connectivity is not yet supported by this driver.
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
Index:
zd1211 chip 0586:3402 v4916 high 00-13-49 AL2230_RF pa0
This device pops up after the virtual driver CD has been ejected.
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
---
zd_usb.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Index:
From: Ulrich Kunitz [EMAIL PROTECTED]
The Longshine device is a ZD1211B and has a AL2230 RF. I tested it
successfully with no encryption and WEP.
Signed-off-by: Ulrich Kunitz [EMAIL PROTECTED]
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
---
zd_usb.c |1 +
1 files changed, 1 insertions(+),
From: Ulrich Kunitz [EMAIL PROTECTED]
Add static to 2 internal functions. Thanks goes to Adrian Bunk, who found that.
Also made some modifications to the clear functions:
After a discussion on the mailing list, I implemented this code to
have on the one hand sufficient test in debug mode, but
Also this won't allow
struct pci_driver {
...
#ifdef CONFIG_PM
int (*suspend)(...);
int (*resume)(...);
#endif
...
};
which is good for a) space savings in CONFIG_PM=n case, and
b) making drivers care
On Tue, Aug 08, 2006 at 04:27:41PM +0200, Lutz Urban wrote:
I'm sorry to tell you that my previous message was bogus. The problem
still persists.
Daniel Drake has posted a fix that's in -mm you can try. It's
probably the least painful solution to date, can you please try that:
On Sat, 12 Aug 2006 10:06:29 -0700
Roland Dreier [EMAIL PROTECTED] wrote:
Also this won't allow
struct pci_driver {
...
#ifdef CONFIG_PM
int (*suspend)(...);
int (*resume)(...);
#endif
...
};
which is good
Folks,
I am not a big readability officianado, but this piece of code has
become a victim of hairy activities over the last few years. So while i
was furiously chasing Herbert's qdisc_is_running changes[1] i made a
small cleanup just so that i could absorb what was going on.
The patch included
Cleanup the NETIF_F_ flag definitions
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
---
include/linux/netdevice.h | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
Index: linux-2.6/include/linux/netdevice.h
Christophe Devriese wrote:
It would however be considerable effort to do this. Is this going to end up
unapplied like my last patch, or ?
I don't get to make this decision..and when I ask such questions...they
are usually ignored unless I also post a working patch
I think you could start
Christophe Devriese wrote:
It would however be considerable effort to do this. Is this going to end up
unapplied like my last patch, or ?
I don't get to make this decision..and when I ask such questions...they
are usually ignored unless I also post a working patch
I think you could start
Peter Zijlstra wrote:
Cleanup the NETIF_F_ flag definitions
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
If you are going to do a cleanup here, you should use the form that
makes it _immediately_ obvious which bit(s) are being used:
#define NETIF_F_SG (1 0)
#define NETIF_F_IP_CSUM
On 12 Aug 2006, [EMAIL PROTECTED] mused:
Then the build froze. I couldn't very well ignore *that*. Perhaps I
couldn't blame XEmacs after all.
It just happened again. It's reproducibly triggered, at least on this
system, by the ocaml-3.09.02 configure script running over NFS (probably
NFS over
From: Peter Zijlstra [EMAIL PROTECTED]
Date: Sat, 12 Aug 2006 12:18:07 +0200
65535 sockets * 128 packets * 16384 bytes/packet =
1^16 * 1^7 * 1^14 = 1^(16+7+14) = 1^37 = 128G of memory per IP
And systems with a lot of IP numbers are not unthinkable.
TCP restricts the amount of global memory
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Sat, 12 Aug 2006 13:37:06 +0400
Does it? I though it is possible to only have 64k of working sockets per
device in TCP.
Where does this limit come from?
You think there is something magic about 64K local ports,
but if remote IP addresses in the
On 08/11/06 01:40, Evgeniy Polyakov wrote:
+/*
+ * Inode events.
+ */
+#define KEVENT_INODE_CREATE 0x1
+#define KEVENT_INODE_REMOVE 0x2
It would be useful to have gnome/kde notification when hard drives start
failing. There was some talk in the past about how to implement
David Miller wrote:
From: Peter Zijlstra [EMAIL PROTECTED]
Date: Sat, 12 Aug 2006 12:18:07 +0200
65535 sockets * 128 packets * 16384 bytes/packet =
1^16 * 1^7 * 1^14 = 1^(16+7+14) = 1^37 = 128G of memory per IP
And systems with a lot of IP numbers are not unthinkable.
TCP restricts the
On Sat, 12 Aug 2006 20:16:03 +0200
Edgar E. Iglesias [EMAIL PROTECTED] wrote:
On Sat, Aug 12, 2006 at 07:13:01PM +0200, Rafael J. Wysocki wrote:
Apparently it doesn't.
Hi, could you try and see if this helps?
Best regards
That looks good, but needs a few more changes for full safety.
On Sat, Aug 12, 2006 at 01:38:35AM -0700, Andrew Morton ([EMAIL PROTECTED])
wrote:
On Sat, 12 Aug 2006 12:18:35 +0400
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
On Fri, Aug 11, 2006 at 08:45:31AM -0700, Andrew Morton ([EMAIL PROTECTED])
wrote:
+static struct lock_class_key
On Sat, 2006-08-12 at 12:47 +0400, Evgeniy Polyakov wrote:
On Fri, Aug 11, 2006 at 11:42:50PM -0400, Rik van Riel ([EMAIL PROTECTED])
wrote:
Dropping these non-essential packets makes sure the reserve memory
doesn't get stuck in some random blocked user-space process, hence
you can make
On Sat, Aug 12, 2006 at 11:19:49AM +0200, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
As you described above, memory for each packet must be allocated (either
from SLAB or from reserve), so network needs special allocator in OOM
condition, and that allocator should be separated from SLAB's
Hi,
On 2.6.18-rc3-mm2 with hotfixes I get things like the appended one on attempts
to suspend to disk. It occurs while devices are being suspended and is fairly
reproducible.
Greetings,
Rafael
Suspending device :01:00.0
Suspending device :02:02.0
Suspending device :02:01.4
On Sat, 2006-08-12 at 13:37 +0400, Evgeniy Polyakov wrote:
On Sat, Aug 12, 2006 at 11:19:49AM +0200, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
As you described above, memory for each packet must be allocated (either
from SLAB or from reserve), so network needs special allocator in OOM
On Sat, Aug 12, 2006 at 12:18:07PM +0200, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
Does it? I though it is possible to only have 64k of working sockets per
device in TCP.
65535 sockets * 128 packets * 16384 bytes/packet =
1^16 * 1^7 * 1^14 = 1^(16+7+14) = 1^37 = 128G of memory per IP
On Sat, Aug 12, 2006 at 02:42:26PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
Hence the alternative allocator to use on tight memory conditions.
If transferred to your implementation, then just steal some pages from
SLAB when new network device is added and use them when OOM
On Sat, 2006-08-12 at 14:42 +0400, Evgeniy Polyakov wrote:
When network uses the same allocator, it depends on it, and thus it is
possible to have (cut by you) a situation when reserve (which depends on
SLAB and it's OOM too) is not filled or even does not exist.
No, the reserve does not
On Sat, Aug 12, 2006 at 01:40:29PM +0200, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
On Sat, 2006-08-12 at 14:42 +0400, Evgeniy Polyakov wrote:
When network uses the same allocator, it depends on it, and thus it is
possible to have (cut by you) a situation when reserve (which depends on
On Sat, 12 Aug 2006 12:07:42 +0200
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
Hi,
On 2.6.18-rc3-mm2 with hotfixes I get things like the appended one on attempts
to suspend to disk. It occurs while devices are being suspended and is fairly
reproducible.
Greetings,
Rafael
Suspending
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Miller wrote:
Please use netdev@vger.kernel.org for discussions about the linux
networking implementation, not [EMAIL PROTECTED]
Kay.
I'm told now that it uses Jiffies for TCP timestamps. I've had thoughts
on this:
- I figured a
Andrew Morton wrote:
It would be good if you could poke around in gdb, work out exactly which
statement it's oopsing at, please.
I'm also interested to know if the problem goes away when you disable
preempt...
Jeff
-
To unsubscribe from this list: send the line unsubscribe netdev
On Sat, Aug 12, 2006 at 09:31:42AM -0400, John Richard Moser ([EMAIL
PROTECTED]) wrote:
I'm told now that it uses Jiffies for TCP timestamps. I've had thoughts
on this:
- I figured a random timestamp with random microsecond skew would be
nice but this might expose internals of the RNG;
Hi,
here the latest effort, it includes a whole new trivial allocator with a
horrid name and an almost full rewrite of the deadlock prevention core.
This version does not do anything per device and hence does not depend
on the new netdev_alloc_skb() API.
The reason to add a second allocator to
The core of the VM deadlock avoidance framework.
From the 'user' side of things it provides a function to mark a 'struct sock'
as SOCK_MEMALLOC, meaning this socket may dip into the memalloc reserves on
the receive side.
When *dev_alloc_skb() finds it cannot allocate a struct sk_buff the
Use sk_set_memalloc() on the nbd socket.
Limit each request to 1 page, so that the request throttling also limits the
number of in-flight pages and force the IO scheduler to NOOP as anything else
doesn't make sense anyway.
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
Signed-off-by: Daniel
Update UML with a proper 'pfn_to_kaddr()' definition, the SROG allocator
uses it.
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
Signed-off-by: Daniel Phillips [EMAIL PROTECTED]
---
include/asm-um/page.h |2 ++
1 file changed, 2 insertions(+)
Index: linux-2.6/include/asm-um/page.h
On Saturday 12 August 2006 14:28, Andrew Morton wrote:
On Sat, 12 Aug 2006 12:07:42 +0200
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
Hi,
On 2.6.18-rc3-mm2 with hotfixes I get things like the appended one on
attempts
to suspend to disk. It occurs while devices are being suspended
On Saturday 12 August 2006 18:12, Edgar E. Iglesias wrote:
On Sat, Aug 12, 2006 at 04:31:18PM +0200, Rafael J. Wysocki wrote:
On Saturday 12 August 2006 14:28, Andrew Morton wrote:
On Sat, 12 Aug 2006 12:07:42 +0200
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
Hi,
On
On Sat, August 12, 2006 16:14, Peter Zijlstra said:
+struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask, int fclone)
+{
+ struct sk_buff *skb;
+
+ skb = ___alloc_skb(size, gfp_mask ~__GFP_MEMALLOC, fclone);
+
+ if (!skb (gfp_mask __GFP_MEMALLOC)
On Sat, 2006-08-12 at 18:51 +0200, Indan Zupancic wrote:
On Sat, August 12, 2006 16:14, Peter Zijlstra said:
Hi,
here the latest effort, it includes a whole new trivial allocator with a
horrid name and an almost full rewrite of the deadlock prevention core.
This version does not do
On Sat, 2006-08-12 at 19:31 +0200, Indan Zupancic wrote:
On Sat, August 12, 2006 16:14, Peter Zijlstra said:
+struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask, int fclone)
+{
+ struct sk_buff *skb;
+
+ skb = ___alloc_skb(size, gfp_mask ~__GFP_MEMALLOC, fclone);
+
+
On Sat, August 12, 2006 19:44, Peter Zijlstra said:
Euhm, right :-) long comes naturaly when I think about quantities op
pages. The adjust_memalloc_reserve() argument is an increment, a delta;
perhaps I should change that to long.
Maybe, but having 16 TB of reserved memory seems plenty for a
On Sat, 2006-08-12 at 19:54 +0200, Indan Zupancic wrote:
On Sat, August 12, 2006 19:44, Peter Zijlstra said:
Euhm, right :-) long comes naturaly when I think about quantities op
pages. The adjust_memalloc_reserve() argument is an increment, a delta;
perhaps I should change that to long.
On Sat, Aug 12, 2006 at 07:13:01PM +0200, Rafael J. Wysocki wrote:
Apparently it doesn't.
Hi, could you try and see if this helps?
Best regards
--
Programmer
Edgar E. Iglesias [EMAIL PROTECTED] 46.46.272.1946
Signed-off-by: Edgar E. Iglesias [EMAIL PROTECTED]
diff --git
On Sat, August 12, 2006 19:33, Peter Zijlstra said:
Simpler yes, but also more complete; the old patches had serious issues
with the alternative allocation scheme.
It sure is more complete, and looks nicer, but the price is IMHO too high.
I'm curious what those serious issues are, and if they
BTW, if anyone would like to be dropped off this growing cc list, please
let us know.
On Fri, Aug 11, 2006 at 12:45:55PM -0700, Ulrich Drepper wrote:
Sébastien Dugué wrote:
aio completion notification
I looked over this now but I don't think I understand everything. Or I
On Sat, August 12, 2006 20:08, Peter Zijlstra said:
On Sat, 2006-08-12 at 19:54 +0200, Indan Zupancic wrote:
True, but currently memalloc_reserve isn't used in a sensible way,
or I'm missing something.
Well, I'm somewhat reluctant to stick network related code into mm/, it
seems well
On Sat, 2006-08-12 at 20:32 +0200, Indan Zupancic wrote:
On Sat, August 12, 2006 20:08, Peter Zijlstra said:
On Sat, 2006-08-12 at 19:54 +0200, Indan Zupancic wrote:
True, but currently memalloc_reserve isn't used in a sensible way,
or I'm missing something.
Well, I'm somewhat reluctant
On Sat, 2006-08-12 at 20:16 +0200, Indan Zupancic wrote:
On Sat, August 12, 2006 19:33, Peter Zijlstra said:
Simpler yes, but also more complete; the old patches had serious issues
with the alternative allocation scheme.
It sure is more complete, and looks nicer, but the price is IMHO too
Suparna Bhattacharya wrote:
I am wondering about that too. IIRC, the IO_NOTIFY_* constants are not
part of the ABI, but only internal to the kernel implementation. I think
Zach had suggested inferring THREAD_ID notification if the pid specified
is not zero. But, I don't see why -sigev_notify
On Saturday 12 August 2006 16:32, Rafael J. Wysocki wrote:
On Saturday 12 August 2006 15:39, Jeff Garzik wrote:
Andrew Morton wrote:
It would be good if you could poke around in gdb, work out exactly which
statement it's oopsing at, please.
I'm also interested to know if the problem
On Saturday 12 August 2006 20:16, Edgar E. Iglesias wrote:
On Sat, Aug 12, 2006 at 07:13:01PM +0200, Rafael J. Wysocki wrote:
Apparently it doesn't.
Hi, could you try and see if this helps?
With the patch I can't reproduce the problem. I sometimes get the error
messages from the interrupt
On Sat, August 12, 2006 20:47, Peter Zijlstra said:
Ah right, I did that in v3, with a similar comment, but I realised that
the inbound reserve need not be per socket, and that the comment was
ambiguous enough to allow this reading.
True, but better to change the comment than to confuse
On Sat, August 12, 2006 20:54, Peter Zijlstra said:
- single allocation group per packet - that is, when I free a packet
and all its associated object I get my memory back.
This is easy.
- not waste too much space managing the various objects
This too, when ignoring clones and COW.
skb
[Cc:ed to l-k and plausible maintainers: I'm not subscribed to netdev
so, please, if you prune l-k, leave me in the Cc]
I just upgraded to 2.6.17.8 (built with GCC 4.1.1 on x86 / Athlon IV).
As luck would have it I made a bunch of other changes at the same time,
namely that I LVMed my root
87 matches
Mail list logo
