On Tue, Dec 04, 2007 at 11:34:32PM -0800, David Miller wrote:
>
> TCP has some built-in assumptions about characteristics of
> interent links and what constitutes a timeout which is "too long"
> and should thus result in a full connection failure.
>
> IPSEC changes this because of IPSEC route res
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 18:16:07 +1100
> Right. This is definitely bad for protocols without a retransmission
> mechanism.
>
> However, is the 0 setting ever useful for TCP and in particular, TCP's
> connect(2) call? Perhaps we can just make that one always dro
On Tue, Dec 04, 2007 at 11:12:00PM -0800, David Miller wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Wed, 5 Dec 2007 17:51:32 +1100
>
> > Does anybody actually need the 0 setting? What would we break if
> > the default became 1?
>
> I bet there are UDP apps out there that would break if w
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 17:51:32 +1100
> Does anybody actually need the 0 setting? What would we break if
> the default became 1?
I bet there are UDP apps out there that would break if we
didn't do this.
Actually, consider even a case like DNS. Let's say the t
On Tue, Dec 04, 2007 at 10:30:23PM -0800, David Miller wrote:
>
> We made an explicit decision not to do things this way.
Thanks for pointing this out.
> Non-blocking has a meaning dependant upon the xfrm_larval_drop sysctl
> setting, and this is across the board. If xfrm_larval_drop is zero,
>
Herbert Xu wrote:
> Denis V. Lunev <[EMAIL PROTECTED]> wrote:
>> could you exactly point me out the flow cache your are talking about.
>> Is this dst entry cache or struct flow_cache described in the
>> net/core/flow.c
>
> The flow object is embedded in struct rtable so does its size change?
>
>
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 11:12:32 +1100
> [INET]: Export non-blocking flags to proto connect call
>
> Previously we made connect(2) block on IPsec SA resolution. This is
> good in general but not desirable for non-blocking sockets.
>
> To fix this properly we'd
On 04-12-2007 23:26, Jarek Poplawski wrote:
...
> But, IMHO, blowing ASSERT_RTNL up in a few places shouldn't be much
> worse. After all, how long such a debugging code should be kept. It
> seems, at least sometimes we should be a bit more confident of how
> it's called.
I see this won't be done t
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Tue, 04 Dec 2007 12:17:57 -0700
> Ben Greear <[EMAIL PROTECTED]> writes:
>
> > If I *do* need to add some sort of namespace
> > awareness to just achieve today's functionality, I don't mind making the
> > changes,
> > so long as I don't need to ch
If you actually run out of the trace buffers, do you just continue to
run with the last settings? If so, that would keep up throughput
even if you are out of trace buffers...
Upon configuring the qdisc you can specify a default value, which is
taken when the buffers are empty. It is either d
[ CCed netdev ]
On Tue, Dec 04, 2007 at 11:59:32PM -0500, Amos Waterland wrote:
> The difference between ip=off and ip=::off has been a cause of much
> confusion. Document how each behaves, and do not contradict ourselves
> by saying that "off" is the default when in fact "any" is the default
From: Ben Greear <[EMAIL PROTECTED]>
Date: Tue, 04 Dec 2007 10:57:01 -0800
> echo add_my_bridge my_br1 eth0 namespaceX eth1 namespaceY >
> /proc/net/foo/config
Each process executes in a namespace, so specifying the namespace
is redundant, just fetch the current process's namespace to pass
into
From: Simon Arlott <[EMAIL PROTECTED]>
Date: Tue, 04 Dec 2007 18:53:19 +
> If I have a IPsec rule like:
> spdadd 192.168.7.8 1.2.3.4 any -P out ipsec esp/transport//require;
> (i.e. a remote host 1.2.3.4 which will not respond)
>
> Then any attempt to communicate with 1.2.3.4 will block
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Tue, 04 Dec 2007 11:03:01 -0700
> I am confused. I don't see a path forward that feels right.
Eric, instead of writing a book about how you feel, look
at the simple facts and resolve this quickly.
You added a new key, the namespace, to the looki
2007/12/5, Herbert Xu <[EMAIL PROTECTED]>:
> The idea is to not touch the unicast stuff at all on the multicast path.
>
> Anyway, this was discussed on netdev so please check the archives because
> there is more to this than just changing the multicast handling. We also
> talked about consolidatin
On Wed, Dec 05, 2007 at 02:30:10PM +0900, Joonwoo Park wrote:
>
> @@ -140,9 +147,11 @@ int dev_mc_sync(struct net_device *to, struct net_device
> *from)
> da = next;
> }
> if (!err)
> - __dev_set_rx_mode(to);
> + pending = __dev_set_rx_mode(to);
>
2007/12/5, Herbert Xu <[EMAIL PROTECTED]>:
> Joonwoo Park <[EMAIL PROTECTED]> wrote:
> > Hi,
> > dev_set_rx_mode calls __dev_set_rx_mode with softirq disabled (by
> > netif_tx_lock_bh)
> > therefore __dev_set_promiscuity can be called with softirq disabled.
> > It will cause in_interrupt() to retu
On Wed, 2007-12-05 at 15:21 +1100, David Gibson wrote:
> On Wed, Dec 05, 2007 at 03:18:49PM +1100, Benjamin Herrenschmidt wrote:
> >
> > On Wed, 2007-12-05 at 14:53 +1100, David Gibson wrote:
> > > It occurred to me the other day. Instead of using a new "unused"
> > > property for this, should w
On Wed, Dec 05, 2007 at 03:18:49PM +1100, Benjamin Herrenschmidt wrote:
>
> On Wed, 2007-12-05 at 14:53 +1100, David Gibson wrote:
> > It occurred to me the other day. Instead of using a new "unused"
> > property for this, should we be using the OF standard "status"
> > property.
>
> Dunno... it
On Wed, 2007-12-05 at 14:53 +1100, David Gibson wrote:
> It occurred to me the other day. Instead of using a new "unused"
> property for this, should we be using the OF standard "status"
> property.
Dunno... it's really not wired. Probably not even clocked.
Ben.
--
To unsubscribe from this li
On Wed, Dec 05, 2007 at 11:14:30AM +1100, Benjamin Herrenschmidt wrote:
> From: Hugh Blemings <[EMAIL PROTECTED]>
>
> Depending on how the 44x processors are wired, some EMAC cells
> might not be useable (and not connected to a PHY). However, some
> device-trees may choose to still expose them (si
My kernel is Linxu 2.6.22.1. SYSFS is off.
When adding an interface to bridge, console will show WARNING message.
If turn SYSFS to on, then the WARNING message is gone.
Any suggestion how to debug this problem? Thanks.
# ifconfig eth0 0.0.0.0
eth0: starting interface.
# brctl addbr br0
# brctl add
On Wed, Dec 05, 2007 at 09:42:45AM +0800, Wang Chen wrote:
>
> I apologize for my miss in previous patch.
>
> Herbert, don't you think the udp6inDatagrams should be counted too
> in xprtsock?
Good point. Here's a better version.
[UDP]: Restore missing inDatagrams increments
The previous m
I can shed light one one detail: ratehalving w/bounding parameters uses
snd_cwnd/4 to be appropriately conservative during slowstart. Ideally cwnd
would be saved for every transmitted segment, and during recovery, ssthresh
and min_cwnd would be set to saved_cwnd/2. However since cwnd is not s
Jeff Garzik wrote:
Chris Snook wrote:
Hey folks --
I've begun cleaning up the atl2 vendor driver for merging. It's
very similar to the atl1 driver, and needs a lot of the same work,
though I have already fixed the 64-bit DMA data corrupter that atl1
users remember so fondly. Right now
Herbert Xu said the following on 2007-12-4 21:01:
> Hi Dave:
>
> You were right about the SUNRPC stuff being missing after all. I'd
> only looked in svcsock.c and missed the call in xprtsock.c.
>
> [UDP]: Restore missing inDatagrams increments
>
> The previous move of the the UDP inDatagrams co
On Tue, 04 Dec 2007 15:07:49 -0500
Jeff Garzik wrote:
> Vitaly Bordug wrote:
> > With that patch fixed.c now fully emulates MDIO bus, thus no need
> > to duplicate PHY layer functionality. That, in turn, drastically
> > simplifies the code, and drops down line count.
> >
> > As an additional bonu
On Wed, Dec 05, 2007 at 12:01:09AM +1100, Herbert Xu wrote:
>
> [UDP]: Restore missing inDatagrams increments
Oops, I got the mode wrong for the SNMP calls.
[UDP]: Restore missing inDatagrams increments
The previous move of the the UDP inDatagrams counter caused the
counting of encapsulated pac
On Wed, Dec 05, 2007 at 12:17:47AM +0100, Jarek Poplawski wrote:
> Bernard, I think you've forgotten at least about some distinct
> changelog and signed-off-by?
>
> Jarek P.
> ---
>
> ax25_subr.c part:
> Acked-by: Jarek Poplawski <[EMAIL PROTECTED]>
The fix for the deadlock due to taking rose_n
Jarek Poplawski wrote:
Bernard Pidoux wrote, On 12/02/2007 06:37 PM:
Hi,
Many thanks for your patch for ~/net/ax25/ax25_subr.c
Introduction of local_bh_disable() ... local_bh_enable()
cured the inconsistent lock state related to AX25 connect timeout.
I have now a stable monoprocessor syste
This updates the copyright notices of the new EMAC driver to
avoid confusion as who is to be blamed for new bugs.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/core.c |5 +
drivers/net/ibm_newemac/core.h |5 +
drivers/net/ibm_newemac/deb
From: Valentine Barshak <[EMAIL PROTECTED]>
This patch fixes a typo in ibm_newemac/core.c
(tah_port should be used instead of tah_ph)
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/core.c |2 +-
1 fi
From: Valentine Barshak <[EMAIL PROTECTED]>
The patch moves dev_set_drvdata(&ofdev->dev, dev) up before tah_reset(ofdev)
is called to avoid a NULL pointer dereference, since tah_reset uses drvdata.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
Signed-off-by: Benjamin Herrenschmidt <[EMAIL
From: Hugh Blemings <[EMAIL PROTECTED]>
Depending on how the 44x processors are wired, some EMAC cells
might not be useable (and not connected to a PHY). However, some
device-trees may choose to still expose them (since their registers
are present in the MMIO space) but with an "unused" property i
From: Valentine Barshak <[EMAIL PROTECTED]>
The EMAC4_MR1_OBCI(freq) macro expects freg in MHz,
while opb_bus_freq is kept in Hz. Correct this.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
diff -pruN linux-2.6.orig/drivers/net
More than just "AXON" version of EMAC RGMII supports MDIO, so replace
the current test with a generic property in the device-tree that
indicates such support.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Acked-by: Stefan Roese <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/sequoia.dt
There are a few variants of the STACR register that affect more than
just the "AXON" version of EMAC. Replace the current test of various
chip models with tests for generic properties in the device-tree.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Acked-by: Stefan Roese <[EMAIL PROTE
From: Stefan Roese <[EMAIL PROTECTED]>
This adds support for the Agere ET1011c PHY as found on the AMCC Taishan
board.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/phy.c | 37 +
When using ZMII for MDIO only (such as 440GX with RGMII for data and ZMII for
MDIO), the ZMII code would fail to properly refcount, thus triggering a
BUG_ON().
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Acked-by: Stefan Roese <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/zmii.c
With some PHYs, when the link goes away, the EMAC reset fails due
to the loss of the RX clock I believe.
The old EMAC driver worked around that using some internal chip-specific
clock force bits that are different on various 44x implementations.
This is an attempt at doing it differently, by avoi
From: Stefan Roese <[EMAIL PROTECTED]>
This patch adds BCM5248 and Marvell 88E PHY support to NEW EMAC driver.
These PHY chips are used on PowerPC 440EPx boards.
The PHY code is based on the previous work by Stefan Roese <[EMAIL PROTECTED]>
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
Sign
On Tue, Dec 04, 2007 at 06:53:19PM +, Simon Arlott wrote:
> If I have a IPsec rule like:
> spdadd 192.168.7.8 1.2.3.4 any -P out ipsec esp/transport//require;
> (i.e. a remote host 1.2.3.4 which will not respond)
>
> Then any attempt to communicate with 1.2.3.4 will block, even when usin
Bernard Pidoux wrote, On 12/04/2007 11:26 PM:
> Jarek Poplawski wrote:
>> Bernard Pidoux wrote, On 12/02/2007 06:37 PM:
>>
>>> Hi,
>>>
>>> Many thanks for your patch for ~/net/ax25/ax25_subr.c
>>>
>>> Introduction of local_bh_disable() ... local_bh_enable()
>>>
>>> cured the inconsistent lock stat
Chris Snook wrote:
Hey folks --
I've begun cleaning up the atl2 vendor driver for merging. It's
very similar to the atl1 driver, and needs a lot of the same work,
though I have already fixed the 64-bit DMA data corrupter that atl1
users remember so fondly. Right now this is very raw, an
Hi folks,
When terminating DSL connections for an assortment of random customers, I've
found it necessary to use iptables to clamp the MSS used for connections to
work around the various ICMP blackholes in the greater net. Unfortunately,
the current behaviour in Linux is imperfect and actually
John W. Linville wrote:
Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
---
Jeff,
I found this one when pushing the latest round of wireless bits
into rawhide. Wanna just go ahead and apply it to netdev-2.6#upstream?
John
drivers/net/wireless/rt2x00/rt2x00lib.h |2 +-
1 files changed
Denis V. Lunev <[EMAIL PROTECTED]> wrote:
>
> could you exactly point me out the flow cache your are talking about.
> Is this dst entry cache or struct flow_cache described in the
> net/core/flow.c
The flow object is embedded in struct rtable so does its size change?
Cheers,
--
Visit Openswan at
Joonwoo Park <[EMAIL PROTECTED]> wrote:
> Hi,
> dev_set_rx_mode calls __dev_set_rx_mode with softirq disabled (by
> netif_tx_lock_bh)
> therefore __dev_set_promiscuity can be called with softirq disabled.
> It will cause in_interrupt() to return true and ASSERT_RTNL warning.
> Is there a good solu
Hey folks --
I've begun cleaning up the atl2 vendor driver for merging. It's very similar
to the atl1 driver, and needs a lot of the same work, though I have already
fixed the 64-bit DMA data corrupter that atl1 users remember so fondly. Right
now this is very raw, and there is a large amou
Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
---
Jeff,
I found this one when pushing the latest round of wireless bits
into rawhide. Wanna just go ahead and apply it to netdev-2.6#upstream?
John
drivers/net/wireless/rt2x00/rt2x00lib.h |2 +-
1 files changed, 1 insertions(+), 1 delet
Joonwoo Park wrote, On 12/04/2007 10:48 AM:
> Hi,
> dev_set_rx_mode calls __dev_set_rx_mode with softirq disabled (by
> netif_tx_lock_bh)
> therefore __dev_set_promiscuity can be called with softirq disabled.
> It will cause in_interrupt() to return true and ASSERT_RTNL warning.
> Is there a good
Ariane Keller wrote:
Yes, for short-term starvation it helps certainly.
But I'm still not convinced that it is really necessary to add more
buffers, because I'm not sure whether the bottleneck is really the
loading of data from user space to kernel space.
Some basic tests have shown that the k
On Tue, 2007-12-04 at 22:45 +0100, Francois Romieu wrote:
> diff --git a/drivers/net/ipg.c b/drivers/net/ipg.c
> index dbd23bb..f736c35 100644
> --- a/drivers/net/ipg.c
> +++ b/drivers/net/ipg.c
> -MODULE_DESCRIPTION("IC Plus IP1000 Gigabit Ethernet Adapter Linux Driver "
> -DrvVer)
Please pull from branch 'ipg' in repository
git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git ipg
to get the changes below.
Distance from 'upstream' (558f08ed31c6909d3c9ae5d6dbf81220ede4b54a)
---
4918e9ebf74735bb8
Ben Greear wrote:
Ariane Keller wrote:
I thought about that as well, but in my opinion this does not help much.
It's the same as before: in average every 10ms a new buffer needs to
be filled.
But, you can fill 50 or 100 at a time, so if user-space is delayed for a
few ms, the
kernel still ha
On Tue, 4 Dec 2007, John Heffner wrote:
> Ilpo Järvinen wrote:
>
> > ...Mind if I ask another similar one, any idea why prior_ssthresh is smaller
> > (3/4 of it) than cwnd used to be (see tcp_current_ssthresh)?
>
> Not sure on that one. I'm not aware of any publications this is based on.
My th
Ilpo Järvinen wrote:
On Tue, 4 Dec 2007, John Heffner wrote:
Ilpo Järvinen wrote:
...I'm still to figure out why tcp_cwnd_down uses snd_ssthresh/2
as lower bound even though the ssthresh was already halved, so snd_ssthresh
should suffice.
I remember this coming up at least once before, so it'
On Tue, 4 Dec 2007, John Heffner wrote:
> Ilpo Järvinen wrote:
> > ...I'm still to figure out why tcp_cwnd_down uses snd_ssthresh/2
> > as lower bound even though the ssthresh was already halved, so snd_ssthresh
> > should suffice.
>
> I remember this coming up at least once before, so it's proba
On Tue, Dec 04, 2007 at 03:14:46PM -0500, Jeff Garzik wrote:
>> Changes to last version:
>> - Use inline functions for dma_sync_* instead of macros (suggested by Ralf)
>> - added Kconfig change to make selection for similair SGI boxes easier
>
> Has Ralf ACK'd this updated version?
Acked-by: Ralf
Lukas Hejtmanek wrote:
> On Tue, Dec 04, 2007 at 09:19:11AM -0800, Kok, Auke wrote:
>> if you "just" want to disable gigabit speed, get the latest ethtool and run:
>>
>>ethtool -s eth0 advertise 0x0f
>>
>
> thanks. You may then let know people behind http://www.lesswatts.org/ to
> change tips&
Thomas Bogendoerfer wrote:
SGI IP28 machines would need special treatment (enable adding addtional
wait states) when accessing memory uncached. To avoid this pain I changed
the driver to use only cached access to memory.
Signed-off-by: Thomas Bogendoerfer <[EMAIL PROTECTED]>
---
Changes to last
Grant Likely wrote:
From: Grant Likely <[EMAIL PROTECTED]>
This patch eliminates the warning of unused return values when the driver
registers it sysfs files. Now the driver will print an error if it is
unable to register the sysfs files.
It also eliminates the macros used to wrap the DEVICE_A
John W. Linville wrote:
Jeff,
Here are more than 5 score patches intended for 2.6.25. This request
replaces the request sent on 27 November. [1]
There are tons of updates here, especially iwlwifi and libertas. The
b43, b43legacy, rt2x00, rtl8187, and zd1211rw drivers are also updated.
This p
Ben Greear <[EMAIL PROTECTED]> writes:
> Ok, but can a netdev at least know what namespace it is in? I don't
> need this for my module, but it seems very useful knowledge...
Sure. dev->nd_net
It is a don't care not a don't know, and there should be device
events when it goes in and out of a ne
Fixes several ugly bugs...
Please pull from 'upstream-fixes' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-fixes
to receive the following updates:
drivers/net/fec_mpc52xx.c|4 ++--
drivers/net/gianfar.c|2 +-
drivers/net/pasemi_mac.
Grant Likely wrote:
From: Grant Likely <[EMAIL PROTECTED]>
Eliminate an uninitialized variable warning. The code is correct, but
a pointer to the automatic variable 'addr' is passed to dma_alloc_coherent.
Since addr has never been initialized, and the compiler doesn't know
what dma_alloc_cohere
Vitaly Bordug wrote:
With that patch fixed.c now fully emulates MDIO bus, thus no need
to duplicate PHY layer functionality. That, in turn, drastically
simplifies the code, and drops down line count.
As an additional bonus, now there is no need to register MDIO bus
for each PHY, all emulated PHY
Anton Vorontsov wrote:
On Tue, Dec 04, 2007 at 08:38:47AM +0100, Thierry Reding wrote:
* Andrew Morton wrote:
On Mon, 3 Dec 2007 09:35:11 +0100 Thierry Reding <[EMAIL PROTECTED]> wrote:
[...]
I've been sitting on
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24
On Nov 28, 2007, at 13:56, David Woodhouse wrote:
This kind of sucks, and prevents the Fedora installer from using the
device for network installs...
[EMAIL PROTECTED] phy]# iwconfig eth0
Warning: Driver for device eth0 has been compiled with an ancient
version
of Wireless Extension, while t
Ben Greear <[EMAIL PROTECTED]> writes:
> I have a module that has a collection of 2-port bridges. These bridges are
> used
> for emulation
> purposes (somewhat similar to netem's feature set). Each bridge is logically
> independent
> of the others. To set up a bridge, I do something like:
>
>
On Tue, Dec 04, 2007 at 09:19:11AM -0800, Kok, Auke wrote:
> if you "just" want to disable gigabit speed, get the latest ethtool and run:
>
>ethtool -s eth0 advertise 0x0f
>
thanks. You may then let know people behind http://www.lesswatts.org/ to
change tips&tricks related to the network. I
Add a field to the lro_mgr struct so that drivers can specify how much
padding is required to align layer 3 headers when a packet is copied
into a freshly allocated skb by inet_lro.c:lro_gen_skb(). Without
padding, skbs generated by LRO will cause alignment warnings on
architectures which requir
Wang Chen wrote:
Peter Korsgaard said the following on 2007-12-3 21:47:
"Wang" == Wang Chen <[EMAIL PROTECTED]> writes:
Hi,
Wang> + len = skb->len;
Wang> netif_rx(skb);
dev-> stats.rx_packets++;
Wang> - dev->stats.rx_bytes += skb->len;
Wang> + dev->stats.rx_bytes += len;
Olof Johansson wrote:
Turns out we're freeing the skb when we detect CRC error, but we're
not clearing out info->skb. We could either clear it and have the stack
reallocate it, or just leave it and the rx ring refill code will reuse
the one that was allocated.
Reusing a freed skb obviously cause
David Woodhouse wrote:
From: Jon Smirl <[EMAIL PROTECTED]>
The mpc5200 fec driver is corrupting memory. This patch fixes two bugs
where the wrong skb was being referenced.
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Acked-by: Domen Puncer <[EMAIL PROTECTED]>
Signed-off-by: Grant Likely <[EMAIL
Stephen Hemminger wrote:
Prevent deadlock in sky2 recovery logic. sky2_down calls napi_synchronize
which gets stuck if napi was already disabled.
Fix by rearranging slightly and not calling napi_disable until after
both ports are stopped. The napi_disable probably is being overly
paranoid, but
David Woodhouse wrote:
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
diff --git a/drivers/net/pasemi_mac.c b/drivers/net/pasemi_mac.c
index 09b4fde..a8db5d7 100644
--- a/drivers/net/pasemi_mac.c
+++ b/drivers/net/pasemi_mac.c
@@ -1362,7 +1362,7 @@ pasemi_mac_probe(struct pci_dev *pdev, cons
Divy Le Ray wrote:
From: Divy Le Ray <[EMAIL PROTECTED]>
revert inavertant file mode changes
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/chelsio/cxgb2.c |0
drivers/net/chelsio/pm3393.c |0
drivers/net/chelsio/sge.c|0
drivers/net/chelsio/sge.h|0
Eric W. Biederman wrote:
Ben Greear <[EMAIL PROTECTED]> writes:
Eric W. Biederman wrote:
However there also seem to be simpler cases like Ben's bridge module,
that don't appear to have any global state.
Well, my module has some global state, but I don't think it needs to care about
namespace
Ben Greear <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> However there also seem to be simpler cases like Ben's bridge module,
>> that don't appear to have any global state.
>>
> Well, my module has some global state, but I don't think it needs to care
> about
> namespaces. My first
Eric W. Biederman wrote:
Ben Greear <[EMAIL PROTECTED]> writes:
Regardless of infringement it is incompatible with a complete network
namespace implementation. Further it sounds like the module you are
describing defines a kernel ABI without being merged and hopes that
ABI will still be sup
If I have a IPsec rule like:
spdadd 192.168.7.8 1.2.3.4 any -P out ipsec esp/transport//require;
(i.e. a remote host 1.2.3.4 which will not respond)
Then any attempt to communicate with 1.2.3.4 will block, even when using
non-blocking sockets:
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
Ilpo Järvinen wrote:
...I'm still to figure out why tcp_cwnd_down uses snd_ssthresh/2
as lower bound even though the ssthresh was already halved,
so snd_ssthresh should suffice.
I remember this coming up at least once before, so it's probably worth a
comment in the code. Rate-halving attempt
Notify that flowi with not initialized fl_net is used. This is a temporary
measure to simplify maintenance of the patchset.
Changes from v1:
- changed BUG_ON to WARN_ON. Thanks to Patrick McHardy
Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
---
net/ipv4/route.c |1 +
net/ipv6/fib6_
Eric W. Biederman wrote:
However there also seem to be simpler cases like Ben's bridge module,
that don't appear to have any global state.
Well, my module has some global state, but I don't think it needs to
care about
namespaces. My first impression is that my module should be able to brid
Stephen Hemminger wrote:
> Can this be made conditional on network namespaces being configured on?
> That way the flow structure won't have to grow taking more space.
> It matters in DoS attacks where flow cache becomes a critical resource.
could you exactly point me out the flow cache your are ta
Chris Friesen <[EMAIL PROTECTED]> wrote:
[...]
>Is there any particular reason why the bonding code couldn't use unicast
>arp packets if the "arp_ip_target" has a valid entry in the sender's arp
>table?
It ought to be a pretty straightforward change to have the
bond_arp_send() function per
On Tue, 2007-12-04 at 18:04 +, David Woodhouse wrote:
> Oops: Exception in kernel mode, sig: 5 [#1]
>
> nfs: server pmac not responding, still trying
Oops, sorry. That was meant to be just to Olof. And it helps if I'm
actually running the kernel i
Ariane Keller wrote:
I thought about that as well, but in my opinion this does not help much.
It's the same as before: in average every 10ms a new buffer needs to
be filled.
But, you can fill 50 or 100 at a time, so if user-space is delayed for a
few ms, the
kernel still has plenty of buffers t
Here is some boilerplate on autoneg which I've been using in other
forums for a number of years when questions about autoneg vs hardcoding
and duplex-mismatch arise:
How 100Base-T Autoneg is supposed to work:
When both sides of the link are set to autoneg, they will "negotiate"
the duplex set
Oops: Exception in kernel mode, sig: 5 [#1]
nfs: server pmac not responding, still trying
SMP NR_CPUS=128 NUMA PA Semi PWRficient
Modules linked in: appletouch cbc blkcipher dm_crypt dm_
Daniel Lezcano <[EMAIL PROTECTED]> writes:
> Ben Greear wrote:
>>> Once things are largely complete it makes sense to argue with out of
>>> tree module authors that because they don't have network namespace
>>> support in their modules, their modules are broken.
>> Does this imply that every modu
Ben Greear <[EMAIL PROTECTED]> writes:
>> Regardless of infringement it is incompatible with a complete network
>> namespace implementation. Further it sounds like the module you are
>> describing defines a kernel ABI without being merged and hopes that
>> ABI will still be supportable in the fut
I thought about that as well, but in my opinion this does not help much.
It's the same as before: in average every 10ms a new buffer needs to be
filled.
Ben Greear wrote:
Ariane Keller wrote:
Increasing the cache size to say 32k for each buffer would be no problem.
Is this enough?
Maybe jus
We have a network with a number of nodes using bonding with arp
monitoring. The arp interval is set to 100ms.
Unfortunately, the bonding code sends the arp packets to the hardware
broadcast address, which means that the number of these arp packets seen
by each node goes up with the number o
Ariane Keller wrote:
Increasing the cache size to say 32k for each buffer would be no problem.
Is this enough?
Maybe just a variable length list of 4k buffers chained together? Its
usually easier
to get 4k chunks of memory than 32k chunks, especially under high
network load,
and if you go ahe
On Tue, Dec 04, 2007 at 04:56:26PM +, Christoph Hellwig ([EMAIL PROTECTED])
wrote:
> > > * fixed bug with XFS metadata update (it can provide slab pages to the
> > > DST, so it is not allowed to transfer them using ->sendpage())
>
> xfs hasn't been doing that anymore for quite a whil
On Tue, 2007-12-04 at 09:07 +0100, Patrick McHardy wrote:
> [NETLINK]: af_netlink.c checkpatch cleanups
> -static __inline__ void
> +static inline void
> netlink_lock_table(void)
> {
> /* read_lock() synchronizes us to netlink_table_grab */
> @@ -208,14 +208,15 @@ netlink_lock_table(void)
>
Lukas Hejtmanek wrote:
> On Tue, Dec 04, 2007 at 11:02:23AM -0500, Matt Mathis wrote:
>> This is probably not an e1000 problem, but a general Ethernet "feature".
>> If you defeat auto-negotiation to force the data rate, you implicitly
>> defeat duplex negotiation as well. You need to explicitly
On Tue, Dec 04, 2007 at 11:02:23AM -0500, Matt Mathis wrote:
> This is probably not an e1000 problem, but a general Ethernet "feature".
> If you defeat auto-negotiation to force the data rate, you implicitly
> defeat duplex negotiation as well. You need to explicitly set the duplex
> mode.
et
1 - 100 of 167 matches
Mail list logo
