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
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 am
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 implem
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 th
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 m
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
[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 files
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.
> sk
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 peop
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_C
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
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 interr
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 w
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 w
On Sat, Aug 12, 2006 at 12:10:35PM -0700, Ulrich Drepper 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
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
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_noti
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 IMH
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 somewh
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 is
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
> > > ...
> >
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
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. O
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
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 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 lon
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: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, fclon
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 n
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) && memall
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:
http://
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,
> > 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
>
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 insertion
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
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 m
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: linux-2.6/drivers/net/wireless/zd1211rw/Makef
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: linux-2.6/drivers/net/wireless/zd1211rw/z
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: linux-2.6/drivers/net/wirel
Some devices identify themselves as a virtual USB CDROM drive. The virtual CD
includes the windows driver. We aren't interested in this, so we eject the
virtual CDROM and then the real wireless device appears.
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/net/wireless/z
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
--- a/drivers/net/wireless/
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: linux-2.6/drivers/net/wireless/zd1211rw/zd_chi
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: linux-2.6/dr
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 netd
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
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");
+}
Ther
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 app
On Sat, 2006-08-12 at 17:28 +0200, Indan Zupancic wrote:
> 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
> >> >
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 kno
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 200
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 be
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
> > +++ linux-2.6/i
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
-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 ra
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 fro
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 @@
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 sepa
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 so
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 b
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
===
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 regula
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
A simple memory allocator with a horrid name.
(if someone knows the proper name of this thing, please speak up.
It's too trivial to not be described somewhere)
Its use is for cases where you have multiple objects of various sizes
that have similar livetimes and should release pages as soon as pos
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 t
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. Mov
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
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"
-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 ran
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
>
>
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 o
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 de
* 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. i
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 f
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
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 hap
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
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
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
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
Suspendi
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
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
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 cl
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, 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
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
li
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
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 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 t
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)
> > > +{
> > > + loc
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
91 matches
Mail list logo
