(apologies for the repost, I thought people may have missed this
question since it was not phrased as such)
I have a hw network device that can benefit from knowing what its
associated IP addresses (if any) are... Is there a "correct" way to
determine the IP address(es) from within the driver cod
This is left over from a previous cleanup of get_property.
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea_main.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
Jeff,
This patch is on top of your upstream branch from today. This change was
in
This is part of the consolidation of the OpenFirmware code ebtween
PowerPC and Sparc.
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
drivers/net/bmac.c |5 +++--
drivers/net/ehea/ehea_main.c |6 +++---
drivers/net/mace.c |4 ++--
drivers/net/pasemi_mac.c
On Thu, 26 Apr 2007, Francois Romieu wrote:
> Align the IP header when the chipset can DMA at any location (plain 0x8169).
> Otherwise (0x8136/0x8168) obey the constraint imposed by the hardware.
>
> This patch complements the previous alignment rework done for copybreak.
>
> Original idea from
On Thu, Apr 26, 2007 at 04:42:47PM -0700, Stephen Hemminger wrote:
> When network device's are renamed, the IPV6 snmp6 code
> gets confused. It doesn't track name changes so it will OOPS
> when network device's are removed.
>
> The fix is trivial, just unregister/re-register in notify handler.
>
From: "John W. Linville" <[EMAIL PROTECTED]>
Date: Thu, 26 Apr 2007 21:50:55 -0400
> From: Johannes Berg <[EMAIL PROTECTED]>
>
> This patch clarifies the comment about locking in wiphy_unregister.
>
> Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
> Signed-off-by: John W. Linville <[EMAIL PROT
From: Johannes Berg <[EMAIL PROTECTED]>
Date: Tue, 24 Apr 2007 20:07:32 +0200
> This patch series contains various cleanups to the wireless extensions code.
All applied, thanks Johannes.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECT
From: "John W. Linville" <[EMAIL PROTECTED]>
Date: Thu, 26 Apr 2007 21:47:44 -0400
> From: Johannes Berg <[EMAIL PROTECTED]>
>
> This patch fixes the locking in wiphy new. Ingo Oeser <[EMAIL PROTECTED]>
> noticed that locking in the error case was wrong and also suggested this
> fix.
>
> Signed-
From: David Miller <[EMAIL PROTECTED]>
Date: Thu, 26 Apr 2007 20:08:09 -0700 (PDT)
> I just found a problem in your work, you cannot use cmpxchg() in
> generic code, it is not available on all processors:
Here is how I'm fixing this for now to get the tree into
a buildable state.
If you have a b
From: David Miller <[EMAIL PROTECTED]>
Date: Thu, 26 Apr 2007 20:12:13 -0700 (PDT)
> And even more problems, what the heck are you doing here?
And even more:
commit 68c708fd5e90f6d178c84bb7e641589eb2842319
Author: David S. Miller <[EMAIL PROTECTED]>
Date: Thu Apr 26 20:20:21 2007 -0700
[R
From: David Miller <[EMAIL PROTECTED]>
Date: Thu, 26 Apr 2007 20:12:13 -0700 (PDT)
> In file included from net/rxrpc/rxkad.c:21:
> net/rxrpc/ar-internal.h:803:1: warning: "atomic_dec" redefined
> In file included from include/linux/spinlock.h:326,
> from include/linux/module.h:9,
> Update required firmware revision to 4.0.0.
Hmm... should we fold this into the earlier patch, which actually
needs this new FW? Or at least merge this patch first?
Also, is it cool with everyone to require a new FW, even for users who
might not be using (or even building) the RDMA driver? I
From: David Miller <[EMAIL PROTECTED]>
Date: Thu, 26 Apr 2007 20:08:09 -0700 (PDT)
> From: David Miller <[EMAIL PROTECTED]>
> Date: Thu, 26 Apr 2007 16:15:22 -0700 (PDT)
>
> > Ok, I applied it all and added a compiler warning fix for 64-bit
> > at the end.
>
> I just found a problem in your work
From: David Miller <[EMAIL PROTECTED]>
Date: Thu, 26 Apr 2007 16:15:22 -0700 (PDT)
> Ok, I applied it all and added a compiler warning fix for 64-bit
> at the end.
I just found a problem in your work, you cannot use cmpxchg() in
generic code, it is not available on all processors:
[EMAIL PROTECT
From: "John W. Linville" <[EMAIL PROTECTED]>
Date: Thu, 26 Apr 2007 21:12:51 -0400
> I'm OK with the whole series.
>
> Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
>
> Good enough? Or would you prefer a git pull request?
Good enough for me.
Thanks John.
-
To unsubscribe from this list:
From: Chuck Ebbert <[EMAIL PROTECTED]>
Date: Thu, 26 Apr 2007 19:10:56 -0400
> Another question: is it a good idea to even be shipping release
> kernels with Mobile IPV6 enabled? Unfortunately, "experimental"
> isn't enough to go by...
There are no known issues in the mobile-ipv6 code to
my knowl
From: Johannes Berg <[EMAIL PROTECTED]>
This patch fixes the locking in wiphy new. Ingo Oeser <[EMAIL PROTECTED]>
noticed that locking in the error case was wrong and also suggested this
fix.
Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
---
From: Johannes Berg <[EMAIL PROTECTED]>
This patch clarifies the comment about locking in wiphy_unregister.
Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
---
I applied this after the "fix locking in wiphy_new" patch, but I
don't think the ord
On Thu, Apr 26, 2007 at 09:53:04AM -0700, Jean Tourrilhes wrote:
> On Tue, Apr 24, 2007 at 08:07:41PM +0200, Johannes Berg wrote:
> > This patch makes the wext bits in struct net_device depend on
> > CONFIG_WIRELESS_EXT.
> >
> > Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
>
> I persona
On Thu, Apr 26, 2007 at 09:46:32AM -0700, Jean Tourrilhes wrote:
> Overall ok with the patches. Comments on a few of them...
> I personally would not remove this DEBUG code, because it
> decreases the overall maitainability of the code.
> First, it does not only help to debug the
On Thu, Apr 26, 2007 at 03:19:21AM -0700, David Miller wrote:
> From: Johannes Berg <[EMAIL PROTECTED]>
> Date: Tue, 24 Apr 2007 20:07:32 +0200
>
> > This patch series contains various cleanups to the wireless extensions code.
>
> I'll wait for Linville to ACK this stuff, then I'll apply it.
I'm
On Thu, Apr 26, 2007 at 01:47:36PM -0400, Neil Horman wrote:
> On Tue, Apr 24, 2007 at 12:43:20PM -0400, Jeff Garzik wrote:
> > Neil Horman wrote:
> > >Hey there-
> > > The sis900 driver appears to have a bug in which the receive routine
> > >passes the skbuff holding the received frame to the ne
David Miller wrote:
Did you actually run sparse to see what warnings this change
adds or deletes or are you submitting untested changes?
I did, and I am aware that sparse shows several warnings
for TIPC, which we will have to fix this asap, of course.
The patched line did not show up in the
In article <[EMAIL PROTECTED]> (at Thu, 26 Apr 2007 19:10:56 -0400), Chuck
Ebbert <[EMAIL PROTECTED]> says:
> Another question: is it a good idea to even be shipping release
> kernels with Mobile IPV6 enabled? Unfortunately, "experimental"
> isn't enough to go by...
Well, we have still 2 missing
When network device's are renamed, the IPV6 snmp6 code
gets confused. It doesn't track name changes so it will OOPS
when network device's are removed.
The fix is trivial, just unregister/re-register in notify handler.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
net/ipv6/addrconf.c
Hello Stephen,
Friday, April 27, 2007, 12:35:17 AM, you wrote:
SH> On Fri, 27 Apr 2007 00:34:43 +0200
SH> speedy <[EMAIL PROTECTED]> wrote:
>> Hello Stephen,
>>
>> Thursday, April 26, 2007, 10:03:39 PM, you wrote:
>>
>> SH> On Thu, 26 Apr 2007 03:59:05 +0200
>> SH> speedy <[EMAIL PROTECTED]> w
From: David Howells <[EMAIL PROTECTED]>
Date: Thu, 26 Apr 2007 20:54:15 +0100
> [This set of patches is built against Dave Miller's net-2.6 GIT tree]
Ok, I applied it all and added a compiler warning fix for 64-bit
at the end.
Thanks for all of your hard work pushing this stuff along David.
com
David Miller wrote:
> From: Chuck Ebbert <[EMAIL PROTECTED]>
> Date: Thu, 26 Apr 2007 17:53:58 -0400
>
>> And what does this do?
>>
>> +switch (hdr->type) {
>> +#ifdef CONFIG_IPV6_MIP6
>> +break;
>> +#endif
>>
>> break by itself like that doesn't do anything. If it did
>> then peop
David Miller wrote:
>> + case IPV6_SRCRT_TYPE_2:
>> + if (accept_source_route >= 0)
>> + break;
>> + kfree_skb(skb);
>> + return -1;
>> + case IPV6_SRCRT_TYPE_0:
>> + if (accept_source_route > 0)
>> +
And here's the patch to convert IPoIB over to using NAPI...
---
Convert the IP-over-InfiniBand network device driver over to using
NAPI to handle all completions (both receive and send).
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
drivers/infiniband/ulp/ipoib/ipoib.h |1 +
dri
On Fri, 27 Apr 2007 00:34:43 +0200
speedy <[EMAIL PROTECTED]> wrote:
> Hello Stephen,
>
> Thursday, April 26, 2007, 10:03:39 PM, you wrote:
>
> SH> On Thu, 26 Apr 2007 03:59:05 +0200
> SH> speedy <[EMAIL PROTECTED]> wrote:
>
> >> Kernel: 2.6.21-rc7
> >> Device: Yukon-EC Ultra (0xb4) rev 2 [inte
From: Chuck Ebbert <[EMAIL PROTECTED]>
Date: Thu, 26 Apr 2007 17:53:58 -0400
> Looking at the patch that went into 2.6.20.9, I can't see
> how type 2 packets get through at all. Shouldn't this part
> read:
>
> + case IPV6_SRCRT_TYPE_2:
> + if (accept_source_route >= 0)
> +
Patrick McHardy wrote:
James Chapman wrote:
Patrick McHardy wrote:
Still the ugly old_data_ready/old_sk_destruct and pppol2tp_fget hacks.
I added comments in the code about why I think pppol2tp_fget is needed.
This driver handles PPP-over-L2TP sockets. These are attached to a plain
UDP (L2TP
From: Chuck Ebbert <[EMAIL PROTECTED]>
Date: Thu, 26 Apr 2007 17:53:58 -0400
> And what does this do?
>
> + switch (hdr->type) {
> +#ifdef CONFIG_IPV6_MIP6
> + break;
> +#endif
>
> break by itself like that doesn't do anything. If it did
> then people with mobile ipv6 enabled wou
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Thu, 26 Apr 2007 14:11:33 -0700
>
> I have this floating about in my tree. Is it of any interest?
I have it too, it's in my backlog which I'm not processing
because I'm trying to fix up how we screwed up both networking
"security" fixes by adding a
Looking at the patch that went into 2.6.20.9, I can't see
how type 2 packets get through at all. Shouldn't this part
read:
+ case IPV6_SRCRT_TYPE_2:
+ if (accept_source_route >= 0)
+ break;
+ kfree_skb(skb);
+ return -1;
+
rtl8169_hw_start will not help maintaining an unified driver for
different chipsets but people at Realtek are probably too polite
to say it distinctly.
Part 1: add the hook and keep hw_start handler unchanged.
As can be seen from the content of rtl8169_pci_tbl, the RTL_CFG_1
entry in rtl_cfg_info
Merged from Realtek's r8169-6.001 driver.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.
Extracted from version 1.001.00 of Realtek's r8101.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index ca4..ad
It has been documented as deprecated:
- in MODULE_PARM_DESC since may 2005 ;
- at the top of the source file and in printk since june 2004.
Good bye.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c | 72 +++--
No functionnal change:
- trim the old history log
- whitespace/indent/case police
- unsigned int where signedness does not matte
- removal of obsolete assert
- needless cast from void * (dev_instance)
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
driver
Part 2: populate the hw_start handlers for the 8168 and the 8101.
- annotate mac_version
- factor out the initialization of the receive and transmit ring
descriptor registers (rtl_set_rx_tx_desc_registers)
- access to the CPlusCmd and setting of the maximum receive size are
idiomatic too (rtl_
- new identifier for the 8110SCe
- the PCI latency timer is set unconditionally. This part is identical
in Realtek's r8168 (8.001.00) and r8101 (1.001.00)
- initialization of the cache line size register is for the 8169s only
- more magic in rtl_hw_start_8169
- it is not possible to factor ou
It is currently limited to 0x8136 and 0x8168. 8169sb/8110sb ought to
handle it as well where they support MSI.
Includes unregister_netdev() fix from Bernhard Walle <[EMAIL PROTECTED]>
against BUG_ON(irq_has_action(dev->first_msi_irq)) (2007/02/24).
Signed-off-by: Francois Romieu <[EMAIL PROTECTED
This one includes:
- more tweaks to rtl_hw_start_8168
- a work around for a Rx FiFO overflow issue on the 8168Bb
- rtl8169_{intr_mask/napi_event} are replaced with per-device fields,
namely tp->{intr/napi}_event
- rtl_cfg_info is converted to C99 for readability but the values are
not
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index e6dbfc9..2cbb63b 100644
--- a/drivers/net/r8169.c
+++ b/driver
The rx copybreak part is straightforward.
The align field in struct rtl_cfg_info is related to the alignment
requirements of the DMA operation. Its value is set at 2 to limit the
scale of possible regression but my old v1.21 8169 datasheet claims a
8 bytes requirements (that was never followed by
Please pull from branch 'r8169-for-jeff' in repository
git://electric-eye.fr.zoreil.com/home/romieu/linux/linux-2.6-out r8169-for-jeff
to get the changes below.
Following mails on netdev describe each patch.
Distance from 'netdev-2.6-upstream' (cbf9d2df24b3222aa70b551f17a216ae6df43d08)
On Tue, 24 Apr 2007 14:02:33 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Kim Phillips wrote:
> > ---
> > this 7 part series supercedes previous 2-set ucc_geth series submitted 10
> > apr 2007.
> > please consider for 2.6.22
> >
> > include/linux/phy.h |1 +
> > 1 files changed, 1 inserti
Align the IP header when the chipset can DMA at any location (plain 0x8169).
Otherwise (0x8136/0x8168) obey the constraint imposed by the hardware.
This patch complements the previous alignment rework done for copybreak.
Original idea from Philip Craig <[EMAIL PROTECTED]>
Signed-off-by: Francois
From: Jon Paul Maloy <[EMAIL PROTECTED]>
Date: Thu, 26 Apr 2007 15:57:55 -0400
> To ease use of sparse, as requested by Ingo Oeser.
>
> Signed-off-by: Jon Paul Maloy <[EMAIL PROTECTED]>
Did you actually run sparse to see what warnings this change
adds or deletes or are you submitting untested ch
From: Jean Tourrilhes <[EMAIL PROTECTED]>
Date: Thu, 26 Apr 2007 10:15:17 -0700
> On Thu, Apr 26, 2007 at 07:03:27PM +0200, Michael Buesch wrote:
> >
> > Sure, other people have different opinions on that, but I think
> > with my approach we get smallest code with good speed.
>
> Try with
From: jamal <[EMAIL PROTECTED]>
Date: Thu, 26 Apr 2007 09:10:10 -0400
> I would have liked to just do a read_lock_bh when retrieving the table
> metadata; however, the state table lock is defined as DEFINE_SPINLOCK
> unlike the policy table which is defined as DEFINE_RWLOCK.
> Any objection to cha
I have this floating about in my tree. Is it of any interest?
From: Jarek Poplawski <[EMAIL PROTECTED]>
* Herbert Xu ([EMAIL PROTECTED]) wrote:
> Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> >
> > My proposal is: maybe Eric could change this in
> > xfrm6_tunnel_rcv() from xfrm6_tunnel.c e.g.
From: jamal <[EMAIL PROTECTED]>
Date: Thu, 26 Apr 2007 08:55:54 -0400
> Here's a missing bit to get in sync with latest net-2.6
Applied, thanks.
-
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.ke
Fail qp creation if the requested max_inline is too large.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/cxio_wr.h |1 +
drivers/infiniband/hw/cxgb3/iwch_provider.c |3 +++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/infin
Update required firmware revision to 4.0.0.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/version.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/cxgb3/version.h b/drivers/net/cxgb3/version.h
index 042e27e..b112317 100644
--- a/dri
Initialize cpu_idx field in cpl_close_listserv_req message.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/iwch_cm.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_cm.c
b/drivers/infiniband/hw/cxgb3/iwch_
Support for new abort logic.
The HW now posts 2 ABORT_RPL and/or PEER_ABORT_REQ messages. We need
to handle them by silenty dropping the 1st but mark that we're ready
for the final message. This plugs some close races between the uP and HW.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
d
Fix TERM codes.
Fix TERMINATE layer, type, and ecode values based on
conformance testing.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/iwch_qp.c | 69 ++---
1 files changed, 38 insertions(+), 31 deletions(-)
diff --git a/drivers/i
Hey Roland,
Here are some bug fixes to the iw_cxgb3 driver that I'd like merged for
2.6.22. The 1st patch has been posted before, but I didn't see it in
your for-2.6.22 branch, so I'm posting it again.
Jeff,
The last patch updates the cxgb3 required firmware version. It is
included in this
Hello,
since the invocation of ipv6_add_dev() at NETDEV_REGISTER time in
addrconf_notify() i get an 'add_dev failed' when registering a netdevice
with a MTU of 16.
As the code doesn't check for ipv6 capable hardware types it simply runs
into an error for some non-ipv6 capable networking hw .
To ease use of sparse, as requested by Ingo Oeser.
Signed-off-by: Jon Paul Maloy <[EMAIL PROTECTED]>
---
net/tipc/msg.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/tipc/msg.h b/net/tipc/msg.h
index 5c64e55..f9f3dd0 100644
--- a/net/tipc/msg.h
+++ b/net/tipc/msg.h
Add support for the CB.GetCapabilities operation with which the fileserver can
ask the client for the following information:
(1) The list of network interfaces it has available as IPv4 address + netmask
plus the MTUs.
(2) The client's UUID.
(3) The extended capabilities of the client, fo
Implement the CB.InitCallBackState3 operation for the fileserver to call.
This reduces the amount of network traffic because if this op is aborted, the
fileserver will then attempt an CB.InitCallBackState operation.
Signed-Off-By: David Howells <[EMAIL PROTECTED]>
---
fs/afs/afs_cm.h|1 +
Update the AFS fs documentation.
Signed-Off-By: David Howells <[EMAIL PROTECTED]>
---
Documentation/filesystems/afs.txt | 214 +++--
1 files changed, 154 insertions(+), 60 deletions(-)
diff --git a/Documentation/filesystems/afs.txt
b/Documentation/filesystems/a
Handle multiple mounts of an AFS superblock correctly, checking to see whether
the superblock is already initialised after calling sget() rather than just
unconditionally stamping all over it.
Also delete the "silent" parameter to afs_fill_super() as it's not used and
can, in any case, be obtained
[This set of patches is built against Dave Miller's net-2.6 GIT tree]
The first of these patches together provide secure client-side RxRPC
connectivity as a Linux kernel socket family. Only the RxRPC transport/session
side is supplied - the presentation side (marshalling the data) is left to the
Export the keyring key type definition and document its availability.
Add alternative types into the key's type_data union to make it more useful.
Not all users necessarily want to use it as a list_head (AF_RXRPC doesn't, for
example), so make it clear that it can be used in other ways.
Signed-Of
Export try_to_del_timer_sync() for use by the AF_RXRPC module.
Signed-Off-By: David Howells <[EMAIL PROTECTED]>
---
kernel/timer.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/kernel/timer.c b/kernel/timer.c
index dd6c2c1..b22bd39 100644
--- a/kernel/timer.c
+++ b/ke
del_timer_sync() buys nothing for cancel_delayed_work(), but it is less
efficient since it locks the timer unconditionally, and may wait for the
completion of the delayed_work_timer_fn().
cancel_delayed_work() == 0 means:
before this patch:
work->func may still be running
On Thu, 26 Apr 2007, Chuck Ebbert wrote:
> Ilpo Järvinen wrote:
> > ...I'm unsure how to continue the investigation from this point onward
> > and asking for ideas/suggestions or how to rule out more possibilities...
> > Or is there some knob which I don't know of that should be toggled or
> >
On Thu, 26 Apr 2007, Rick Jones wrote:
> Ilpo Järvinen wrote:
> >
> > ...
> > Some time ago I noticed that with 2.6.18 I occassionally get latency
> > spikes as long as 100-200ms in the TCP transfers between components
> > (I describe later how TCP was tuned during these tests to avoid
> > proble
On Apr 25 2007 10:45, Waskiewicz Jr, Peter P wrote:
>>
>> BTW, is there any reason this is being cced to lkml?
>
>Since this change affects how tc interacts with the qdisc layer, I cced
>lkml.
Fine with me, at least I get to know that tc could break :)
Jan
--
-
To unsubscribe from this list:
Hi
I'm relatively new to Linux, IPsec and this mailing list, so let me know if
I've posted to the wrong list or if this mail is out-of-scope.
Background
--
I'm looking to develop an application that will set up IPsec security
associations (SAs) and policy on demand and then use those
Jeff Garzik wrote:
Ayaz Abdulla wrote:
I don't see why the NAPI handler needs to process tx packets. The ISR
will handle all tx processing.
It is a design choice, not a requirement.
Moving non-RX interrupt processing to the NAPI handler can help as loads
increase. The basic idea is to d
On Tue, Apr 24, 2007 at 12:43:20PM -0400, Jeff Garzik wrote:
> Neil Horman wrote:
> >Hey there-
> > The sis900 driver appears to have a bug in which the receive routine
> >passes the skbuff holding the received frame to the network stack before
> >refilling the buffer in the rx ring. If a new
Ayaz Abdulla wrote:
I don't see why the NAPI handler needs to process tx packets. The ISR
will handle all tx processing.
It is a design choice, not a requirement.
Moving non-RX interrupt processing to the NAPI handler can help as loads
increase. The basic idea is to do as much work as possib
Hello,
I got a panic from a freshly installed vanilla 2.6.21 kernel.
I have a Sony Vaio PCG-GRT815E with a SiS900 ethernet card.
Here is the error message (as handcopied from a camera shot,
please ask for the original .jpeg if you need it):
= BUG MESSAGE BEGINS
BU
I don't see why the NAPI handler needs to process tx packets. The ISR
will handle all tx processing.
[EMAIL PROTECTED] wrote:
From: Ingo Molnar <[EMAIL PROTECTED]>
Another forcedeth.c thing: i noticed that its NAPI handler does not do
tx-ring processing. The patch below implements this - tes
On Thu, 2007-04-26 at 09:50 -0700, Jean Tourrilhes wrote:
> That's clearly not true of all compilers. All gcc versions
> before 4.0 need serious help to inline functions used only once. Our
> current minimal requirement for the kernel is gcc 3.2, therefore this
> code is still useful.
>
On Thu, Apr 26, 2007 at 07:03:27PM +0200, Michael Buesch wrote:
>
> Sure, other people have different opinions on that, but I think
> with my approach we get smallest code with good speed.
Try with gcc-3.3 if you don't trust me. Your patch will
produce bigger and slower code. Thanks.
This patch fixes the locking in wiphy new. Ingo Oeser <[EMAIL PROTECTED]>
noticed that locking in the error case was wrong and also suggested this
fix.
Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
---
As with other patches, this is diffed against wireless-dev but applies
against net-2.6.22 (o
On Thu, 2007-04-26 at 09:53 -0700, Jean Tourrilhes wrote:
> I personally would not do that. Having conditional fields in
> "struct net_device" is very bad, it's a sure way to crash on modules
> in some cases. If I remember well, Jeff Garzik has been fighting those
> over the years.
I'm fine
On Thursday 26 April 2007 18:50:32 Jean Tourrilhes wrote:
> On Tue, Apr 24, 2007 at 08:07:39PM +0200, Johannes Berg wrote:
> > This patch removes a bunch of inline abuse from wext. Most functions
> > that were marked inline are only used once so the compiler will inline
> > them anyway, others are
On Tue, Apr 24, 2007 at 08:07:39PM +0200, Johannes Berg wrote:
> This patch removes a bunch of inline abuse from wext. Most functions
> that were marked inline are only used once so the compiler will inline
> them anyway, others are used multiple times but there's no requirement
> for them to be in
On Tue, Apr 24, 2007 at 08:07:41PM +0200, Johannes Berg wrote:
> This patch makes the wext bits in struct net_device depend on
> CONFIG_WIRELESS_EXT.
>
> Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
I personally would not do that. Having conditional fields in
"struct net_device" is ve
> Waskiewicz Jr, Peter P wrote:
> >>I wouldn't object to putting this into a completely new scheduler
> >>(sch_multiqueue) though since the scheduling policy might
> be something
> >>completely different than strict priority.
> >
> >
> > We have plans to write a new qdisc that has no priority
On Tue, Apr 24, 2007 at 08:07:35PM +0200, Johannes Berg wrote:
> This patch kills a whole bunch of code that can only ever be used by
> defining some things in wext.c. Also, the things that are printed are
> mostly useless since the API is fairly well-tested.
>
> Signed-off-by: Johannes Berg <[EMA
Waskiewicz Jr, Peter P wrote:
>>I wouldn't object to putting this into a completely new scheduler
>>(sch_multiqueue) though since the scheduling policy might be
>>something completely different than strict priority.
>
>
> We have plans to write a new qdisc that has no priority given to any
> skb
Ilpo Järvinen wrote:
Hi,
...
Some time ago I noticed that with 2.6.18 I occassionally get latency
spikes as long as 100-200ms in the TCP transfers between components
(I describe later how TCP was tuned during these tests to avoid
problems that occur with small segments). I started to investigate
> jamal wrote:
> > On Wed, 2007-25-04 at 10:45 -0700, Waskiewicz Jr, Peter P wrote:
> >
> >>The previous version of my multiqueue patches I sent for
> consideration
> >>had feedback from Patrick McHardy asking that the user be able to
> >>configure the PRIO qdisc to run with multiqueue support
From: Jesse Brandeburg <[EMAIL PROTECTED]>
let the module parameter for invalid eeprom checksum control the valid
mac address test.
If this bypass happens we should print a different message,
or at least one that is correct, maybe something like below
Signed-off-by: Jesse Brandeburg <[EMAIL PROT
From: Jesse Brandeburg <[EMAIL PROTECTED]>
I/O access mode. Setting the new parameter use_io=1 will cause
all driver instances to use io mapping to access the register
space on the e100 device.
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
Lennart Sorensen wrote:
>
> My suspicision (although it is only that) is that the PXA255 trying to
> access memory may cause interruptions in PCI bus master transfers, which
> is of course not permitted by the PCI spec (at least the way I read it).
Why wouldn't that be permitted? It, in fact, ha
Jeff Garzik wrote:
Kok, Auke wrote:
Jeff, I think I should just push the IO patch and the sbit code to
Andrew and have it sit there. That is a vastly larger test resource than
we currently can generate for this. If needed we just let is sit there
for a whole release cycle before moving it to #
Ilpo Järvinen wrote:
> ...I'm unsure how to continue the investigation from this point onward
> and asking for ideas/suggestions or how to rule out more possibilities...
> Or is there some knob which I don't know of that should be toggled or
> something, is 2.6 network stack expected to behave t
Hello!
> When CONFIG_IP_MULTIPLE_TABLES is enabled, the code in nl_fib_lookup()
> needs to initialize the res.r field before fib_res_put(&res) - unlike
> fib_lookup(), a direct call to ->tb_lookup does not set this field.
Indeed, I am sorry.
Alexey
-
To unsubscribe from this list: send the line
Kok, Auke wrote:
Jeff Garzik wrote:
Lennert Buytenhek wrote:
This is all a while ago now, but wasn't the e100 S-bit patch originally
written by Intel people in response to the very same quote by Russell
King that you've quoted above?
Correct.
I just wanted to make sure it didn't kill any box
When CONFIG_IP_MULTIPLE_TABLES is enabled, the code in nl_fib_lookup()
needs to initialize the res.r field before fib_res_put(&res) - unlike
fib_lookup(), a direct call to ->tb_lookup does not set this field.
Signed-off-by: Sergey Vlasov <[EMAIL PROTECTED]>
---
net/ipv4/fib_frontend.c |4
1 - 100 of 192 matches
Mail list logo
