From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sat, 5 May 2007 15:33:43 +1000
> [NETLINK]: Remove references to process ID
>
> People treating the *_pid fields in netlink as a process ID has caused
> endless confusion over the years. The fact that our own netlink.h
> does this only adds to the confu
From: "John W. Linville" <[EMAIL PROTECTED]>
Date: Sat, 5 May 2007 01:26:35 -0400
> On Fri, May 04, 2007 at 11:17:49PM -0400, John W. Linville wrote:
>
> > The wireless developers would like this to be considered for merge
> > in time for 2.6.22. Patches for at least one mac80211-based driver
>
Hi Dave:
[NETLINK]: Remove references to process ID
People treating the *_pid fields in netlink as a process ID has caused
endless confusion over the years. The fact that our own netlink.h
does this only adds to the confusion.
So here is a patch to change the comments to refer to it as the port
On Fri, May 04, 2007 at 11:17:49PM -0400, John W. Linville wrote:
> The wireless developers would like this to be considered for merge
> in time for 2.6.22. Patches for at least one mac80211-based driver
> will follow shortly.
Ooops! I forgot to add a "From: Jiri Benc..." line to the top of
the
The network device frontend driver allows the kernel to access network
devices exported exported by a virtual machine containing a physical
network device driver.
* * *
use skb.cb for storing private data
Netfront's use of nh.raw and h.raw for storing page+offset is a bit
hinky, and it breaks wit
This series adds the mac80211 component. This is the new wireless
infrastructure for "softmac"-style wireless hardware. It originated
as code contributed by Devicescape, and has been under development by
the community for well over a year. Thanks are due especially to Jiri
Benc and Michael Wu as
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Fri, 4 May 2007 19:50:10 -0700
> In a small number of cases, we really get a ton of spurious interrupts.
> We have even seen the kernel shutting off IRQ7 because of too many
> unclaimed spurious interrupts.
Ok, that's a big problem.
In retrospect th
David Miller wrote:
> From: "Michael Chan" <[EMAIL PROTECTED]>
> Date: Fri, 04 May 2007 18:45:58 -0700
>
> > We had a discussion about 2 years ago and David decided to
> > remove the I/O read to improve performance. Since then a
> > small number of users have been complaining about spurious
> >
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Fri, 04 May 2007 18:45:58 -0700
> We had a discussion about 2 years ago and David decided to remove the
> I/O read to improve performance. Since then a small number of users
> have been complaining about spurious interrupts. We can add back the
> un
Hi Dave,
these are the Bluetooth fixes for the 2.6.22 kernel release. Please pull
and send them of to Linus as soon as possible since one of them actually
fixes an information leak.
Regards
Marcel
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6.gi
On Fri, 2007-05-04 at 20:42 -0400, Jeff Garzik wrote:
> Michael Chan wrote:
> > [TG3]: Reduce spurious interrupts.
> >
> > Spurious interrupts are often encountered especially on systems
> > using the 8259 PIC mode. This is because the I/O write to deassert
> > the interrupt is posted and won't g
Michael Chan wrote:
[TG3]: Reduce spurious interrupts.
Spurious interrupts are often encountered especially on systems
using the 8259 PIC mode. This is because the I/O write to deassert
the interrupt is posted and won't get to the chip immediately. As
a result, the IRQ may remain asserted afte
Well, Segher doesn't want me to use iobarrier (because it's not I/O).
Andy doesn't want me to use wmb() (because it's sync). I don't think
something like gfar_wmb() would be appropriate. So the remaining
options are either eieio(),
? Just curious... the original intent of eieio was to order I/
Michael Chan wrote:
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -3019,6 +3019,15 @@ static int tg3_setup_phy(struct tg3 *tp, int force_reset)
}
}
+ if (tp->tg3_flags & TG3_FLAG_ASPM_WORKAROUND) {
+ u32 val = tr32(0x7d28);
+ if (!netif_
Michael Chan wrote:
@@ -10404,6 +10400,8 @@ static void __devinit tg3_read_fw_ver(struct tg3 *tp)
}
}
+static struct pci_dev * __devinit tg3_find_peer(struct tg3 *);
+
static int __devinit tg3_get_invariants(struct tg3 *tp)
{
static struct pci_device_id write_reorder_chipset
Michael Chan wrote:
[TG3]: Eliminate the TG3_FLAG_5701_REG_WRITE_BUG flag.
This patch removes the use of the TG3_FLAG_5701_REG_WRITE_BUG flag.
Signed-off-by: Matt Carlson <[EMAIL PROTECTED]>
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
ACK, though the patch description is a bit unclear /wh
Michael Chan wrote:
[TG3]: Eliminate the TG3_FLAG_GOT_SERDES_FLOWCTL flag.
This flag does not do anything useful.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
ACK patches 1-6
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
[TG3]: Add TG3_FLAG_SUPPORT_MSI flag.
And fix up the code to always allow MSI on 5714 A2.
Call tg3_find_peer() earlier because we need that information before
we can determine whether we can set TG3_FLAG_SUPPORT_MSI or not.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/ne
[TG3]: Add ASPM workaround.
This patch adds workaround to fix performance problems caused by slow
PCIE L1->L0 transitions on ICH8 platforms.
Signed-off-by: Matt Carlson <[EMAIL PROTECTED]>
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 4f
[TG3]: Reduce spurious interrupts.
Spurious interrupts are often encountered especially on systems
using the 8259 PIC mode. This is because the I/O write to deassert
the interrupt is posted and won't get to the chip immediately. As
a result, the IRQ may remain asserted after the IRQ handler exit
[TG3]: Update version and reldate.
Update version to 3.76.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index c264eb0..7124924 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -64,8 +64,8 @@
#define DRV_MODULE_NAME
[TG3]: Remove reset during MAC address changes.
The reset was added a while back so that ASF could re-init whatever
MAC address it wanted to use after the MAC address was changed.
Instead of resetting, we can just keep MAC address 1 unchanged during
MAC address changes if MAC address 1 is differen
[TG3]: Eliminate the TG3_FLAG_GOT_SERDES_FLOWCTL flag.
This flag does not do anything useful.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 6094d6b..84fc498 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -2595,10 +2595,8 @@ st
[TG3]: Eliminate the TG3_FLAG_5701_REG_WRITE_BUG flag.
This patch removes the use of the TG3_FLAG_5701_REG_WRITE_BUG flag.
Signed-off-by: Matt Carlson <[EMAIL PROTECTED]>
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 84fc498..23a9477 100
[TG3]: Improve NVRAM sizing.
This patch changes the NVRAM sizing procedure so that the driver can
take advantage of devices with 1:1 NVRAM strapping configurations. This
is useful in cases where the traditional NVRAM sizing method fails. In
the event that the flash size cannot be determined, the
[TG3]: Clear GPIO mask before storing.
The GPIO settings may change during reset and so the stored values in
tp->grc_local_ctrl should be cleared first.
Signed-off-by: Gary Zambrano <[EMAIL PROTECTED]>
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/t
[TG3]: WoL fixes.
Change TG3_FLAG_SERDES_WOL_CAP to TG3_FLAG_WOL_CAP to make it easier
to manage WoL. This flag is now used consistently during ethtool WoL
setup and power setting changes.
Signed-off-by: Gary Zambrano <[EMAIL PROTECTED]>
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --gi
[TG3]: Fix TSO bugs.
1. Remove the check for skb->len greater than MTU when doing TSO.
When the destination has a smaller MSS than the source, a TSO packet
may be smaller than the MTU and we still need to process it as a TSO
packet.
2. On 5705A3 devices with TSO enabled, the DMA engine can hang d
On Fri, May 04, 2007 at 05:13:09PM -0500, Linas Vepstas wrote:
> On Wed, May 02, 2007 at 03:40:20PM -0500, Scott Wood wrote:
> >
> > Well, Segher doesn't want me to use iobarrier (because it's not I/O).
> > Andy doesn't want me to use wmb() (because it's sync). I don't think
> > something like
Hi,
I attach a diff against 2.6.21 for adding wpa support for airo driver.
In then end of 2005 I manage to make work wpa but the code was really
ugly. I manage to find some time to clean it.
To support wpa, a new interface of the firmware should be used. This
interface is incompatible with t
On Wed, May 02, 2007 at 03:40:20PM -0500, Scott Wood wrote:
>
> Well, Segher doesn't want me to use iobarrier (because it's not I/O).
> Andy doesn't want me to use wmb() (because it's sync). I don't think
> something like gfar_wmb() would be appropriate. So the remaining
> options are either
David Acker wrote:
So far my testing has shown both the original and the new version of the
S-bit patch work in that no corruption seemed to occur over long term
runs.
I spoke too soon. Further testing has not gone well. If I use the
default settings for CPU saver and drop the receive pool
Daniel Walker wrote:
On Fri, 2007-05-04 at 12:26 +0200, Peter Zijlstra wrote:
1) introduce the memory reserve and make the SLAB allocator play nice with it.
patches 01-10
2) add some needed infrastructure to the network code
patches 11-13
3) implement the idea outlined above
patch
On Fri, 2007-05-04 at 13:43 -0700, Waskiewicz Jr, Peter P wrote:
> If hardware exists that wants the granularity to
> start/stop queues independent of each other and continue to have
> traffic
> flow, I really think it should be able to do that.
Not much of an if there, I'm pretty sure at least s
From: "Waskiewicz Jr, Peter P" <[EMAIL PROTECTED]>
Date: Fri, 4 May 2007 13:43:43 -0700
> And if someone can explain to me why 2 months of review and scrutiny
> of these patches has shifted in another direction, I'd really like
> to understand that.
One reason is that you're sort of making it cle
From: Vlad Yasevich <[EMAIL PROTECTED]>
Date: Fri, 4 May 2007 16:44:18 -0400
> During the INIT/COOKIE-ACK collision cases, it's possible to get
> into a situation where the association id is not yet set at the time
> of the user event generation. As a result, user events have an
> association id
During the INIT/COOKIE-ACK collision cases, it's possible to get
into a situation where the association id is not yet set at the time
of the user event generation. As a result, user events have an
association id set to 0 which will confuse applications.
This happens if we hit case B of duplicate
> Just because they want to standardize, and put it in hardware
> doesn't mean it is a good idea and Linux needs to support it!
I gave this as the motivation for the original idea. But these patches
have been under scrutiny in the community for months now, and nobody
seemed to think they were to
From: Vlad Yasevich <[EMAIL PROTECTED]>
Date: Fri, 4 May 2007 16:22:55 -0400
> From: Sridhar Samudrala <[EMAIL PROTECTED]>
>
> Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>
> Signed-off-by: Vlad Yasevich <[EMAIL PROTECTED]>
Applied, thanks.
-
To unsubscribe from this list: send the line
From: Vlad Yasevich <[EMAIL PROTECTED]>
Date: Fri, 4 May 2007 16:22:54 -0400
> During the INIT/COOKIE-ACK collision cases, it's possible to get
> into a situation where the association id is not yet set at the time
> of the user event generation. As a result, user events have an
> association id
From: Vlad Yasevich <[EMAIL PROTECTED]>
Date: Fri, 4 May 2007 16:22:52 -0400
> We need to make sure that all destination ports are the same, since
> the association really must not connect to multiple different ports
> at once. This was reported on the sctp-impl list.
>
> Signed-off-by: Vlad Ya
From: Vlad Yasevich <[EMAIL PROTECTED]>
Date: Fri, 4 May 2007 16:22:53 -0400
> Update the SO_REUSEADDR handling to also check for listen state. This
> was muliple listening server sockets can't be created and they will
> not steal packets from each other.
> Reported by Paolo Galtieri <[EMAIL PRO
David Miller wrote:
From: Peter Zijlstra <[EMAIL PROTECTED]>
Date: Fri, 04 May 2007 21:41:49 +0200
How would you prefer I present these?
How about 8 or 9 at a time? You are building infrastructure
and therefore you could post them 1 at a time for review
since each patch should be able to sta
We need to make sure that all destination ports are the same, since
the association really must not connect to multiple different ports
at once. This was reported on the sctp-impl list.
Signed-off-by: Vlad Yasevich <[EMAIL PROTECTED]>
---
net/sctp/socket.c |8
1 files changed, 8 ins
[ sory for possible duplicates, mail server problems ]
Hi David
This a set of 4 bug fixes for SCTP. Please apply.
Thanks
-vlad
-
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/majord
During the INIT/COOKIE-ACK collision cases, it's possible to get
into a situation where the association id is not yet set at the time
of the user event generation. As a result, user events have an
association id set to 0 which will confuse applications.
This happens if we hit case B of duplicate
Update the SO_REUSEADDR handling to also check for listen state. This
was muliple listening server sockets can't be created and they will
not steal packets from each other.
Reported by Paolo Galtieri <[EMAIL PROTECTED]>
Signed-off-by: Vlad Yasevich <[EMAIL PROTECTED]>
---
net/sctp/socket.c | 3
From: Sridhar Samudrala <[EMAIL PROTECTED]>
Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>
Signed-off-by: Vlad Yasevich <[EMAIL PROTECTED]>
---
include/net/sctp/sctp.h |4 ++
net/sctp/ipv6.c | 49
net/sctp/protocol.c | 79
Hi David
This is a set of recent bufixes to SCTP. Please apply.
Thanks
-vlad
-
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
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Fri, 4 May 2007 13:01:10 -0700
> Just because they want to standardize, and put it in hardware doesn't
> mean it is a good idea and Linux needs to support it!
>
> Why is it better for hardware to make the "next packet to send" decision?
> For wire
On Thu, 3 May 2007 14:03:07 -0700
"Waskiewicz Jr, Peter P" <[EMAIL PROTECTED]> wrote:
> > Lets come up with some terminology; lets call multiqueue what
> > the qdiscs do; lets call what the NICs do multi-ring.
> > Note, i have thus far said you need to have both and they
> > must be in sync.
>
From: Peter Zijlstra <[EMAIL PROTECTED]>
Date: Fri, 04 May 2007 21:41:49 +0200
> How would you prefer I present these?
How about 8 or 9 at a time? You are building infrastructure
and therefore you could post them 1 at a time for review
since each patch should be able to stand on it's own.
-
To u
On Fri, 4 May 2007, Pekka Enberg wrote:
> Christoph Lameter wrote:
> > On Fri, 4 May 2007, Pekka Enberg wrote:
> >
> > > Again, slab has no way of actually estimating how many pages you need for
> > > a
> > > given number of objects. So we end up calculating some upper bound which
> > > doesn't b
On Fri, 4 May 2007, Pekka Enberg wrote:
> Christoph Lameter wrote:
> > SLAB can calculate exactly how many pages are needed. The per cpu and per
> > node stuff is setup at boot and does not change. We are talking about the
> > worst case scenario here. True in case of an off slab
> > we have addit
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Fri, 04 May 2007 20:10:44 +0200
> Here they are, thanks for your patience :)
>
> I've changed them to XFRMA_SAD_... and XFRMA_SPD_... since
> UNSPEC and MAX are usually seperated by an underscore.
Applied, thanks everyone.
-
To unsubscribe from thi
From: "Mike Snitzer" <[EMAIL PROTECTED]>
Date: Fri, 4 May 2007 14:09:40 -0400
> These suggestions conflict in the case of a large patchset: the second
> can't be met if you honor the first (more important suggestion IMHO).
> Unless you leave something out... and I can't see the value in leaving
>
On Fri, 2007-05-04 at 12:27 -0700, David Miller wrote:
> From: Peter Zijlstra <[EMAIL PROTECTED]>
> Date: Fri, 04 May 2007 12:26:51 +0200
>
> > There is a fundamental deadlock associated with paging;
>
> I know you'd really like people like myself to review this work, but a
> set of 40 patches is
From: David Howells <[EMAIL PROTECTED]>
Date: Fri, 04 May 2007 15:56:47 +0100
> Sort out the MTU determination and handling in AF_RXRPC:
>
> (1) If it's present, parse the additional information supplied by the peer at
> the end of the ACK packet (struct ackinfo) to determine the MTU sizes
From: Pavel Emelianov <[EMAIL PROTECTED]>
Date: Fri, 04 May 2007 18:51:36 +0400
> Make access to udphash/udplitehash symmetrical to inet hashes.
>
> This may also help network namespaces, since they tend to use
> one hash for different namespaces by selecting the hash chain
> depending on a hash
On Fri, 2007-05-04 at 14:09 -0400, Mike Snitzer wrote:
> On 5/4/07, Daniel Walker <[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-05-04 at 17:38 +0200, Peter Zijlstra wrote:
> > > >
> > > > This is kind of a lot of patches all at once .. Have you release any of
> > > > these patch sets prior to this re
From: Peter Zijlstra <[EMAIL PROTECTED]>
Date: Fri, 04 May 2007 12:26:51 +0200
> There is a fundamental deadlock associated with paging;
I know you'd really like people like myself to review this work, but a
set of 40 patches is just too much to try and digest at once
especially when I have other
From: Frank Pavlic <[EMAIL PROTECTED]>
Date: Fri, 4 May 2007 11:52:38 +0200
> From: Heiko Carstens <[EMAIL PROTECTED]>
>
> Add missing section annotations and found and fixed some
> Coding Style issues.
>
> Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
> Signed-off-by: Frank Pavlic <[EMAIL P
From: Frank Pavlic <[EMAIL PROTECTED]>
Date: Fri, 4 May 2007 11:51:34 +0200
> From: Jennifer Hunt <[EMAIL PROTECTED]>
>
> With the inital implementation we missed to implement a skb backlog
> queue . The result is that socket receive processing tossed packets.
> Since AF_IUCV connections are work
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Fri, 04 May 2007 21:02:56 +0200
> [NETLINK]: Remove bogus BUG_ON
>
> Remove bogus BUG_ON(mutex_is_locked(nlk_sk(sk)->cb_mutex)), when the
> netlink_kernel_create caller specifies an external mutex it might
> validly be locked.
>
> Signed-off-by: Pa
Andrew Morton wrote:
> kernel BUG at net/netlink/af_netlink.c:144!
The BUG_ON(mutex_is_locked(nlk_sk(sk)->cb_mutex)) is bogus,
this patch removes it.
[NETLINK]: Remove bogus BUG_ON
Remove bogus BUG_ON(mutex_is_locked(nlk_sk(sk)->cb_mutex)), when the
netlink_kernel_create caller specifies an ext
On Fri, May 04, 2007 at 11:24:33AM -0700, Don Fry wrote:
> All instances of obtaining the lock in pcnet32 are done as
> spin_lock_irqsave except the interrupt handler itself. The interrupt mask
> needs to be saved everywhere else, but the interrupt handler is known not
> to need to save the flags.
All instances of obtaining the lock in pcnet32 are done as
spin_lock_irqsave except the interrupt handler itself. The interrupt mask
needs to be saved everywhere else, but the interrupt handler is known not
to need to save the flags.
If the lock is held and the same CPU tries to get the lock agai
My last pull was yesterday:
GIT fc38582db98533066f4ba64f948720483fbfe7b2
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
commit
Author: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu May 3 03:36:16 2007 -0700
[NETFILTER]: bridge netfilter: consolidate header push
Christoph Lameter wrote:
On Fri, 4 May 2007, Pekka Enberg wrote:
Again, slab has no way of actually estimating how many pages you need for a
given number of objects. So we end up calculating some upper bound which
doesn't belong in mm/slab.c. I am perfectly okay with:
It can give a worst case
Christoph Lameter wrote:
SLAB can calculate exactly how many pages are needed. The per
cpu and per node stuff is setup at boot and does not change. We are
talking about the worst case scenario here. True in case of an off slab
we have additional overhead that would also have to go into worst cas
On Fri, 4 May 2007, Pekka Enberg wrote:
> Again, slab has no way of actually estimating how many pages you need for a
> given number of objects. So we end up calculating some upper bound which
> doesn't belong in mm/slab.c. I am perfectly okay with:
It can give a worst case number and that is wha
On Fri, 4 May 2007, Pekka Enberg wrote:
> > which would calculate the worst case memory scenario for allocation the
> > number of indicated objects?
>
> IIRC this looks more or less what Peter had initially. I don't like the API
> because there's no way for slab (perhaps this is different for slu
On Fri, 2007-05-04 at 11:30 -0700, Christoph Lameter wrote:
> Hmmm... Maybe lets have
>
> unsigned kmem_estimate_pages(struct kmem_cache *slab_cache, int objects)
>
> which would calculate the worst case memory scenario for allocation the
> number of indicated objects?
On Fri, 4 May 2007, Pete
Christoph Lameter wrote:
Hmmm... Maybe lets have
unsigned kmem_estimate_pages(struct kmem_cache *slab_cache, int objects)
which would calculate the worst case memory scenario for allocation the
number of indicated objects?
IIRC this looks more or less what Peter had initially. I don't like t
On Fri, 2007-05-04 at 11:30 -0700, Christoph Lameter wrote:
> On Fri, 4 May 2007, Peter Zijlstra wrote:
>
> > > Ok so you really need the number of objects per page? If you know the
> > > number of objects then you can calculate the pages needed which would be
> > > the maximum memory needed?
>
On Fri, 4 May 2007, Peter Zijlstra wrote:
> > Ok so you really need the number of objects per page? If you know the
> > number of objects then you can calculate the pages needed which would be
> > the maximum memory needed?
>
> Yes, that would work.
Hmmm... Maybe lets have
unsigned kmem_estim
On Fri, 2007-05-04 at 11:04 -0700, Christoph Lameter wrote:
> On Fri, 4 May 2007, Peter Zijlstra wrote:
>
> > > I could add a function that tells you how many object you could allocate
> > > from a slab without the page allocator becoming involved? It would count
> > > the object slots available
jamal wrote:
> On Fri, 2007-04-05 at 02:19 +0200, Patrick McHardy wrote:
>
>
>>If you dont mind I'm just going to resend myself with fixed
>>names tomorrow so you don't have to bother doing this again.
>
>
> If you have the cycles please go ahead. Otherwise i could do it
> in a couple of days.
On 5/4/07, Daniel Walker <[EMAIL PROTECTED]> wrote:
On Fri, 2007-05-04 at 17:38 +0200, Peter Zijlstra wrote:
> >
> > This is kind of a lot of patches all at once .. Have you release any of
> > these patch sets prior to this release ?
>
> Like the -v12 suggests, this is the 12th posting of this pa
On Fri, 4 May 2007, Peter Zijlstra wrote:
> > I could add a function that tells you how many object you could allocate
> > from a slab without the page allocator becoming involved? It would count
> > the object slots available on the partial slabs.
>
> I need to know how many pages to reserve t
On Fri, 13 Apr 2007 03:48:22 +0200 Pallai Roland wrote:
> I've got a problem with my DFE-580TX cards when I installed thoose into
> a new server box. One card has been worked before in a test box,
> it's sure, here is a dmesg snippet when everything was OK:
>
> Apr 3 22:10:38 cyrax kernel: sunda
On Fri, 2007-05-04 at 09:36 -0700, Christoph Lameter wrote:
> On Fri, 4 May 2007, Peter Zijlstra wrote:
>
> > Expost buffer_size in order to allow fair estimates on the actual space
> > used/needed.
>
> If its just an estimate that you are after then I think ksize is
> sufficient.
>
> The buff
On Fri, May 04, 2007 at 01:44:56PM -0400, Lennart Sorensen wrote:
> On Fri, May 04, 2007 at 11:40:09AM -0400, Lennart Sorensen wrote:
> > On Fri, May 04, 2007 at 05:34:38PM +0200, Frederik Deweerdt wrote:
> > > For the "what" part, see Documentation/lockdep-design.txt. You'll enable
> > > it by wit
On Fri, May 04, 2007 at 11:40:09AM -0400, Lennart Sorensen wrote:
> On Fri, May 04, 2007 at 05:34:38PM +0200, Frederik Deweerdt wrote:
> > For the "what" part, see Documentation/lockdep-design.txt. You'll enable
> > it by with SPINLOCK_DEBUG, indeed.
>
> Well I hope to see it hit the BUG again soo
On Fri, 4 May 2007, Peter Zijlstra wrote:
> Expost buffer_size in order to allow fair estimates on the actual space
> used/needed.
If its just an estimate that you are after then I think ksize is
sufficient.
The buffer size does not include the other per slab overhead that SLAB
needs nor the
On Fri, 2007-05-04 at 09:23 -0700, Christoph Lameter wrote:
> On Fri, 4 May 2007, Peter Zijlstra wrote:
>
> > On Fri, 2007-05-04 at 09:09 -0700, Christoph Lameter wrote:
> > > On Fri, 4 May 2007, Pekka Enberg wrote:
> > >
> > > > On 5/4/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > > > > Expo
On Fri, 4 May 2007, Peter Zijlstra wrote:
> On Fri, 2007-05-04 at 09:09 -0700, Christoph Lameter wrote:
> > On Fri, 4 May 2007, Pekka Enberg wrote:
> >
> > > On 5/4/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > > > Expost buffer_size in order to allow fair estimates on the actual space
> > >
On Fri, 2007-05-04 at 09:09 -0700, Christoph Lameter wrote:
> On Fri, 4 May 2007, Pekka Enberg wrote:
>
> > On 5/4/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > > Expost buffer_size in order to allow fair estimates on the actual space
> > > used/needed.
>
> We already have ksize?
ksize gives
NetXen: Changes related to registers and their access routines
This patch updates the various access routines to access different
control and status settings present in different register locations.
This will fix problems related to working of different ports in
multi Port card.
Signed-off by:
On Fri, 4 May 2007, Pekka Enberg wrote:
> On 5/4/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > Expost buffer_size in order to allow fair estimates on the actual space
> > used/needed.
We already have ksize?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a
NetXen: Fix for driver on System-p
This patch will fix a ping issue on system-p.
Signed-off by: Milan Bag <[EMAIL PROTECTED]>
Signed-off by: Adhiraj Joshi <[EMAIL PROTECTED]>
Signed-by: Mithlesh Thukral <[EMAIL PROTECTED]>
---
drivers/net/netxen/netxen_nic_init.c |2 +-
1 files changed, 1
hi All,
Thanks for your feedback Christoph. I have dropped that conditional
checking of pdev->class in this patchset.
These patches are wrt netdev#upstream.
Regards,
Mithlesh Thukral
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTE
On Fri, 2007-05-04 at 17:38 +0200, Peter Zijlstra wrote:
> >
> > This is kind of a lot of patches all at once .. Have you release any of
> > these patch sets prior to this release ?
>
> Like the -v12 suggests, this is the 12th posting of this patch set.
> Some is the same, some has changed.
I c
> Let me see if i got this right:
> This new standard sends _flow control_ packets per 802.1p value?
Yes.
> Sounds a bit fscked. I am assuming that the link flow control
> is still on (not that i am a big fan).
No, it is not. They're mutually exclusive.
> Is Datacenter ethernet the name of th
On Fri, May 04, 2007 at 05:34:38PM +0200, Frederik Deweerdt wrote:
> For the "what" part, see Documentation/lockdep-design.txt. You'll enable
> it by with SPINLOCK_DEBUG, indeed.
Well I hope to see it hit the BUG again soon then to see what it has to
say.
--
Len Sorensen
-
To unsubscribe from thi
On Fri, 2007-05-04 at 08:22 -0700, Daniel Walker wrote:
> On Fri, 2007-05-04 at 12:26 +0200, Peter Zijlstra wrote:
>
> > 1) introduce the memory reserve and make the SLAB allocator play nice with
> > it.
> >patches 01-10
> >
> > 2) add some needed infrastructure to the network code
> >pa
On Fri, May 04, 2007 at 11:19:34AM -0400, Lennart Sorensen wrote:
> On Fri, May 04, 2007 at 04:33:26PM +0200, Frederik Deweerdt wrote:
> > On Fri, May 04, 2007 at 10:10:24AM -0400, Lennart Sorensen wrote:
> > > On Thu, May 03, 2007 at 04:31:43PM -0400, Lennart Sorensen wrote:
> > [...]
> > > Should
On Fri, 2007-05-04 at 12:26 +0200, Peter Zijlstra wrote:
> 1) introduce the memory reserve and make the SLAB allocator play nice with it.
>patches 01-10
>
> 2) add some needed infrastructure to the network code
>patches 11-13
>
> 3) implement the idea outlined above
>patches 14-20
>
On Fri, May 04, 2007 at 04:33:26PM +0200, Frederik Deweerdt wrote:
> On Fri, May 04, 2007 at 10:10:24AM -0400, Lennart Sorensen wrote:
> > On Thu, May 03, 2007 at 04:31:43PM -0400, Lennart Sorensen wrote:
> [...]
> > Should line 2563 be a spin_lock_irqsave instead along with the
> > appropriate unl
Sort out the MTU determination and handling in AF_RXRPC:
(1) If it's present, parse the additional information supplied by the peer at
the end of the ACK packet (struct ackinfo) to determine the MTU sizes
that peer is willing to support.
(2) Initialise the MTU size to that peer from t
1 - 100 of 173 matches
Mail list logo
