David Miller wrote:
From: Masahide NAKAMURA <[EMAIL PROTECTED]>
Date: Thu, 12 Apr 2007 14:42:00 +0900
Hello,
I sent the patch, which is required for IPsec usage by Mobile IPv6.
I have not obtained any comments yet. Does anybody have it?
I hope it to be applied.
It is in my backlog. I was s
From: Masahide NAKAMURA <[EMAIL PROTECTED]>
Date: Thu, 12 Apr 2007 14:42:00 +0900
> Hello,
>
> I sent the patch, which is required for IPsec usage by Mobile IPv6.
> I have not obtained any comments yet. Does anybody have it?
>
> I hope it to be applied.
It is in my backlog. I was struggling wi
Hello,
I sent the patch, which is required for IPsec usage by Mobile IPv6.
I have not obtained any comments yet. Does anybody have it?
I hope it to be applied.
Thanks,
Masahide NAKAMURA wrote:
> On MIPv6 usage, XFRM sub policy is enabled.
> When main (IPsec) and sub (MIPv6) policy selectors ha
On Wed, 11 Apr 2007, Ben Greear wrote:
> The problem is that I set up a TCP connection with bi-directional traffic
> of around 800Mbps, doing large (20k - 64k writes and reads) between two ports
> on
> the same machine (this 2.6.18.2 kernel is tainted with my full patch set,
> but I also reproduce
Bartek wrote:
> Hopefully, this time it my bug report should be ok :):
>
> Apr 11 23:53:38 localhost pppd[31289]: rcvd [proto=0x7689] e1 cd 33 f6
> fd f7 52 e6 58 c9 73 98 bc ff ad d5 b5 a3 e5 d9 1e 77 76 0a 1c 87 59
> bf 44 cc ac 3b ...
> Apr 11 23:53:38 localhost pppd[31289]: Unsupported protoco
On Wed, 2007-04-11 at 19:03 +0200, Patrick McHardy wrote:
>
> You bring up a good point, it would be good to hear the opinion from
> one of the wireless people on this since they have their own
> multiqueue scheduler in the wireless-dev tree.
The one in the wireless-dev is pretty much like this
Rusty Russell wrote:
> On Wed, 2007-04-11 at 17:28 +0300, Avi Kivity wrote:
>
>> Rusty Russell wrote:
>>
>>> On Wed, 2007-04-11 at 07:26 +0300, Avi Kivity wrote:
>>>
>>>
Nope. Being async is critical for copyless networking:
>> With async operations, the s
I also noticed this happening with 2.6.18 kernel version, but this was
not severe with linux 2.6.20.3. So, the short-term solution will be
upgrading to the latest kernel of FC-6.
A long black-out is mostly observed when a lot of packet losses
happened in slow start. You can prevent this by apply
On Wed, Apr 11, 2007 at 02:06:31PM -0700, Ben Greear wrote:
> For the dup acks, I see nothing *but* dup acks on the wire...going in
> both directions interestingly, at greater than 100,000 packets per second.
>
> I don't mind adding printks...and I've started reading through the code,
> but there
On Wed, Apr 11, 2007 at 04:36:49PM -0500, Kim Phillips wrote:
> > On Tue, Apr 10, 2007 at 04:57:23PM -0500, Kim Phillips wrote:
> >
> > > also adds RX & TX delay bits to help boards with clock skew
> > > problems.
> >
>
> >
> > > [...]
> > > +
> > > + temp |= (MII_M_RX_DELAY | MII_
On Wed, 2007-04-11 at 17:28 +0300, Avi Kivity wrote:
> Rusty Russell wrote:
> > On Wed, 2007-04-11 at 07:26 +0300, Avi Kivity wrote:
> >
> >> Nope. Being async is critical for copyless networking:
> >>
> With async operations, the saga continues like this: the host-side
> driver allocates an s
-stable review patch. If anyone has any objections, please let us know.
--
From: Stephen Hemminger <[EMAIL PROTECTED]>
Some of these chips are disabled until clock is enabled.
This fixes:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=404107
Signed-off-by: Stephen Hemming
-stable review patch. If anyone has any objections, please let us know.
--
From: Stephen Hemminger <[EMAIL PROTECTED]>
The workaround Yukon EC-U wasn't comparing with correct
version and wasn't doing correct setup. Without it, 88e8056
throws all sorts of errors.
Signed-off-by: S
-stable review patch. If anyone has any objections, please let us know.
--
From: Stephen Hemminger <[EMAIL PROTECTED]>
Driver needs to turn off carrier when down.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
dri
-stable review patch. If anyone has any objections, please let us know.
--
From: Stephen Hemminger <[EMAIL PROTECTED]>
Driver needs to turn off carrier when down, otherwise it can
confuse bonding and bridging and looks like carrier is on immediately
when it is brought back up.
S
The Yukon EC Ultra chips have transmit settings for store and
forward and PCI buffering. By setting these appropriately, normal
performance goes from 750Mbytes/sec to 940Mbytes/sec (non-jumbo).
It is also possible to do Jumbo mode, but it means turning off
TSO and checksum offload so the performan
These address issues found testing EC-U (88E8056 and 88E8055) chips.
--
Stephen Hemminger <[EMAIL PROTECTED]>
-
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
Need to make sure and disable ASF on all chip types. Otherwise, there may be
random reboots.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/sky2.c | 18 --
1 files changed, 8 insertions(+), 10 deletions(-)
--- sky2-2.6.21.orig/drivers/net/sky2.c 2007-04-11
The Yukon FE (100mbit only) chips do not support large packets.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- sky2-2.6.21.orig/drivers/net/sky2.c 2007-04-11 14:40:42.0 -0700
+++ sky2-2.6.21/drivers/net/sky2.c 2007-04-11 14:41:09.0 -0700
@@ -1899,6 +1899,9 @@ static
There should never be descriptor error unless hardware or driver is buggy.
But if an error occurs, print useful information, clear irq, and recover.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/sky2.c | 67
drivers/net
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- sky2-2.6.21.orig/drivers/net/sky2.c 2007-04-11 14:41:09.0 -0700
+++ sky2-2.6.21/drivers/net/sky2.c 2007-04-11 14:44:24.0 -0700
@@ -49,7 +49,7 @@
#include "sky2.h"
#define DRV_NAME "sky2"
-#define DRV_VE
This device is having all sorts of problems that lead to data corruption
and system instability. It gets receive status and data out of order,
it generates descriptor and TSO errors, etc.
Until the problems are resolved, it should not be used by anyone
who cares about there system.
Signed-off-by
On Wed, 11 Apr 2007 03:03:56 +0200
Lennert Buytenhek <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 10, 2007 at 05:20:52PM -0500, Kim Phillips wrote:
>
> > (note I'm coming from an embedded world here.)
>
> Please read this:
>
> http://marc.info/?l=linux-netdev&m=116527863300952&w=2
Not sure h
From: Ben Greear <[EMAIL PROTECTED]>
Date: Wed, 11 Apr 2007 14:31:00 -0700
> I've spent solid weeks tracking down obscure races.
I've spent solid weeks tracking down kernel stack corruption and scsi
problems on sparc64, as well as attending to my network maintainer
duties, what is your point?
>
On Wed, 11 Apr 2007 03:01:58 +0200
Lennert Buytenhek <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 10, 2007 at 04:57:23PM -0500, Kim Phillips wrote:
>
> > also adds RX & TX delay bits to help boards with clock skew
> > problems.
>
>
> > [...]
> > +
> > + temp |= (MII_M_RX_DELAY | MII_
David Miller wrote:
From: Ben Greear <[EMAIL PROTECTED]>
Date: Wed, 11 Apr 2007 14:06:31 -0700
Does the CWND == 1 count as solid? Any idea how/why this would go
to 1 in conjunction with the dup acks?
For the dup acks, I see nothing *but* dup acks on the wire...going in
both directions interes
From: Ben Greear <[EMAIL PROTECTED]>
Date: Wed, 11 Apr 2007 14:06:31 -0700
> Does the CWND == 1 count as solid? Any idea how/why this would go
> to 1 in conjunction with the dup acks?
>
> For the dup acks, I see nothing *but* dup acks on the wire...going in
> both directions interestingly, at gr
David Miller wrote:
From: Ben Greear <[EMAIL PROTECTED]>
Date: Wed, 11 Apr 2007 13:26:36 -0700
Interestingly, I found this page mentioning a SACK problem in Linux:
http://www-didc.lbl.gov/TCP-tuning/linux.html
Don't read that page, it is the last place in the world your should
take hints and
From: Ben Greear <[EMAIL PROTECTED]>
Date: Wed, 11 Apr 2007 13:26:36 -0700
> Interestingly, I found this page mentioning a SACK problem in Linux:
> http://www-didc.lbl.gov/TCP-tuning/linux.html
Don't read that page, it is the last place in the world your should
take hints and advice from, most of
From: Ben Greear <[EMAIL PROTECTED]>
Date: Wed, 11 Apr 2007 11:50:18 -0700
> So, I would like to dig into this problem myself since no one else
> is reporting this type of problem, but I am quite ignorant of the TCP
> stack implementation. Based on the dup-acks I see on the wire, I assume
> the T
Ben Greear wrote:
Back in May of last year, I reported this problem, but worked
around it at the time by changing the kernel memory settings
in the networking stack. I reproduced the problem again today
with the previously working kernel memory settings..which is not
supprising since I just pape
On Wed, Apr 11, 2007 at 09:10:32PM +0100, David Howells wrote:
> J. Bruce Fields <[EMAIL PROTECTED]> wrote:
>
> > Just curious--when is the actual crypto done? There doesn't seem to be
> > any in this patch.
>
> See AF_RXRPC patch:
>
> http://people.redhat.com/~dhowells/rxrpc/04-af_rxrpc.
J. Bruce Fields <[EMAIL PROTECTED]> wrote:
> Just curious--when is the actual crypto done? There doesn't seem to be
> any in this patch.
See AF_RXRPC patch:
http://people.redhat.com/~dhowells/rxrpc/04-af_rxrpc.diff
You turn on CONFIG_RXKAD and load the rxkad module thus built (assuming
On Wed, Apr 11, 2007 at 08:10:37PM +0100, David Howells wrote:
> Add security support to the AFS filesystem. Kerberos IV tickets are
> added as RxRPC keys are added to the session keyring with the klog
> program. open() and other VFS operations then find this ticket with
> request_key() and eithe
Correctly alter the relocation state after update is complete by switching it
from "Updating" to "Valid".
Also display the record state in the vlocation database proc file.
Signed-Off-By: David Howells <[EMAIL PROTECTED]>
---
fs/afs/proc.c | 15 +--
fs/afs/vlocation.c |4
Make two changes to the AF_RXRPC key handling to make it easier for AFS to
use:
(1) Export key_type_rxrpc so that AFS can request keys of this type.
(2) Make it possible to have keys that represent "no security". These are
created by instantiating the keys with no data.
Signed-Off-By: Da
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
Permit a key to be cached in the nameidata struct so that it only needs to be
looked up once when doing the sequence of d_revalidate(), permission(),
follow_link() and lookup() calls involved in a pathwalk.
This is used by the AFS filesystem to avoid repeatedly having to call
request_key(). Once
Make the AF_RXRPC module use its own workqueues with their own per-CPU threads.
Currently it uses keventd to do the following tasks, amongst others:
(*) Security negotiation
(*) Packet encryption and decryption
(*) Packet resending
(*) ACK, abort and busy packet generation
(*) Timeout han
Make a couple of fixes to AF_RXRPC:
(1) The dead call timeout is shortened to 2 seconds. Without this, each
completed call sits around eating up resources for 10 seconds. The calls
need to hang around for a little while in case duplicate packets appear,
but 10 seconds is excessiv
Fix a deadlock in the give-up-callback aggregator dispatcher work item whereby
the aggregator runs on keventd as does timed autounmount, thus leading to the
unmount blocking keventd whilst waiting for keventd to run the aggregator when
the give-up-callback buffer is full.
Signed-Off-By: David Howe
These patches build on the patchset labelled "AF_RXRPC socket family and AFS
rewrite". The patches are also available for http download.
Firstly, the patches fix a number of bugs in AF_RXRPC:
http://people.redhat.com/~dhowells/rxrpc/09-af_rxrpc-own-workqueues.diff
http://people.
This is a note to let you know that we have just queued up the patch titled
Subject: 8139too: RTNL and flush_scheduled_work deadlock
to the 2.6.20-stable tree. Its filename is
8139too-rtnl-and-flush_scheduled_work-deadlock.patch
A git repo of this tree can be found at
http://w
This is a note to let you know that we have just queued up the patch titled
Subject: 8139too: RTNL and flush_scheduled_work deadlock
to the 2.6.20-stable tree. Its filename is
8139too-rtnl-and-flush_scheduled_work-deadlock.patch
A git repo of this tree can be found at
http://w
Back in May of last year, I reported this problem, but worked
around it at the time by changing the kernel memory settings
in the networking stack. I reproduced the problem again today
with the previously working kernel memory settings..which is not
supprising since I just papered over the bug la
Jeff Garzik wrote:
>> @@ -2526,6 +2530,18 @@
>> PCI_DEVICE_ID_SERVERWORKS_HT2100_PCIE_FIRST
>> && bridge->device <=
>> PCI_DEVICE_ID_SERVERWORKS_HT2100_PCIE_LAST)
>> +/* All Intel E3000/E3010 PCIE ports */
>> +|| (br
Andrew Morton wrote:
> On Wed, 11 Apr 2007 02:37:01 -0700 [EMAIL PROTECTED] wrote:
>
>
>>http://bugzilla.kernel.org/show_bug.cgi?id=8320
>>
>> Summary: replacing route in kernel doesn't send netlink message
>>Kernel Version: 2.6.20.6
>>Status: NEW
>> Severity: l
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/cxgb3/common.h |7 +-
drivers/net/cxgb3/cxgb3_main.c | 16 ++--
drivers/net/cxgb3/cx
On Wed, 11 Apr 2007 07:19:46 +0200
Patrick McHardy <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger wrote:
> > diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
> > index a260679..8a55276 100644
> > --- a/net/bridge/br_input.c
> > +++ b/net/bridge/br_input.c
> > if (unlikely(is_link_loc
Waskiewicz Jr, Peter P wrote:
>>Packets will only be dequeued from a band if the associated
>>subqueue is active, which moves the decision from prio to the
>>driver, no?
>>What policy does e1000 use for scheduling its internal queues?
>>
>
>
> E1000 is handed the skb's from PRIO to whichever qu
On Wed, 2007-04-11 at 18:52 +0200, Patrick McHardy wrote:
> I'm not sure I'm following. I was under the impression that the
> conclusion of yesterdays discussion was that its probably not
> worth using rtnetlink for wireless so it will continue to use
> generic netlink exclusively, but even if tha
> Thanks.
>
> > However, the PRIO qdisc still uses the priority in the bands for
> > dequeueing priority, and will feed the queues on the NIC.
> > The e1000, and any other multiqueue NIC, will schedule Tx
> based on how
> > the PRIO qdisc feeds the queues. So the only priority here is the
> >
Johannes Berg wrote:
> On Wed, 2007-04-11 at 18:15 +0200, Patrick McHardy wrote:
>
>> But you have a valid point, if we want to use
>>this for things like bonding or VLAN that aren't actually address
>>families, we should consider introducing "rtnetlink families" to
>>avoid adding AF_BONDING, AF_8
On Wed, 11 Apr 2007 02:37:01 -0700 [EMAIL PROTECTED] wrote:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=8320
>
>Summary: replacing route in kernel doesn't send netlink message
> Kernel Version: 2.6.20.6
> Status: NEW
> Severity: low
> Owner:
On Wed, 2007-04-11 at 18:15 +0200, Patrick McHardy wrote:
> No, generic netlink avoids allocating netlink families.
Well, yes, I thought that was pretty much the point. :)
> br_netlink
> uses the same netlink family as the other network configuration stuff
> (NETLINK_ROUTE), but a different rtg
On Tue, 10 Apr 2007 23:16:59 +0200
Johannes Berg <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-04-10 at 02:06 +0200, Patrick McHardy wrote:
>
> > Same way as the current RTM_SETLINK message works, but with creating
> > a new link in advance. It works fine in other subsystems, so I don't
> > see why i
Johannes Berg wrote:
> On Tue, 2007-04-10 at 02:06 +0200, Patrick McHardy wrote:
>
>
>>Same way as the current RTM_SETLINK message works, but with creating
>>a new link in advance. It works fine in other subsystems, so I don't
>>see why it would in this case as well. Some subsystems do it in an
>
[EMAIL PROTECTED] wrote:
From: Divy Le Ray <[EMAIL PROTECTED]>
Fix a deadlock when the interface s configured down and
the watchdog tack is sleeping on rtnl_lock.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/cxgb3_main.c |4 +++-
1 files changed, 3 insertions(+),
Brice Goglin wrote:
Simpler way of dealing with the firmware 4KB boundary crossing
restriction for rx buffers. This fixes a variety of memory
corruption issues when using an "uncommon" MTU with a 16KB
page size.
Signed-off-by: Brice Goglin <[EMAIL PROTECTED]>
---
drivers/net/myri10ge/myri10ge.
Brice Goglin wrote:
Add the Intel 5000 southbridge (aka Intel 6310/6311/6321ESB) PCIe ports
and the Intel E30x0 chipsets to the whitelist of aligned PCIe completion.
Signed-off-by: Brice Goglin <[EMAIL PROTECTED]>
---
drivers/net/myri10ge/myri10ge.c | 17 +
1 file changed, 17
Stephen Hemminger wrote:
Driver needs to turn off carrier when down, otherwise it can
confuse bonding and bridging and looks like carrier is on immediately
when it is brought back up.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- netdev-2.6.orig/drivers/net/skge.c 2007-04-07 15:09:1
> >>>+ skb->queue_mapping =
> >>>+
> q->prio2band[q->band2queue[band&TC_PRIO_MAX]];
> >>
> >>
> >>Does this needs to be cleared at some point again? TC actions might
> >>redirect or mirror packets to other (multiqueue) devices.
> >
> >
> > If an skb is
Well, I found that with CentOS/Fedora/RHEL, I could use their standard
network-scripts to create VLAN devices.
I got VLAN devices running OK, but then ended up in the same boat as
before.
Also, it might be nice if keepalived/LVS had the option of entering a
VLAN device in keepalived.conf? (might
Hi Oscar
Isaula Oscar-QOI000 wrote:
> I ran into a problem where LKSCTP is reporting a SCTM_COMM_UP indication
> to the User application but is giving back a value of zero for the
> assoc_id.
>
> Attached are the SCTP debugs for the period in question.
>
> A couple of things that I would like to
Rusty Russell wrote:
On Wed, 2007-04-11 at 07:26 +0300, Avi Kivity wrote:
Nope. Being async is critical for copyless networking:
- in the transmit path, so need to stop the sender (guest) from touching
the memory until it's on the wire. This means 100% of packets sent will
be blocked.
On Wed, 2007-04-11 at 07:26 +0300, Avi Kivity wrote:
> Nope. Being async is critical for copyless networking:
>
> - in the transmit path, so need to stop the sender (guest) from touching
> the memory until it's on the wire. This means 100% of packets sent will
> be blocked.
Hi Avi,
You
On Wed, Apr 11, 2007 at 10:15:51PM +1000, Rusty Russell wrote:
>
> Actually, I did this precisely because I really didn't want to start
> exposing bogus stats in /proc/net/dev. An audit might clarify if this
> is an actual issue.
Fair enough. Still returning zeros when get_stats isn't available
On Wed, 2007-04-11 at 17:56 +1000, Herbert Xu wrote:
> Hi:
>
> [NET]: Get rid of NETIF_F_INTERNAL_STATS
>
> The recently added NETIF_F_INTERNAL_STATS isn't very useful. If the
> device driver needs to set it then it can always override get_stats
> instead. All existing drivers that have stats (
On Tue, 2007-04-10 at 02:06 +0200, Patrick McHardy wrote:
> Same way as the current RTM_SETLINK message works, but with creating
> a new link in advance. It works fine in other subsystems, so I don't
> see why it would in this case as well. Some subsystems do it in an
> atomic fashion (network sch
Waskiewicz Jr, Peter P <[EMAIL PROTECTED]> wrote:
>
> True, but the assignment for "dev" above also casts this void * to
> struct net_device *:
>
>dev = (struct net_device *)
>(((long)p + NETDEV_ALIGN_CONST) & ~NETDEV_ALIGN_CONST);
>dev->padded = (char *)dev - (cha
On Tue, 10 Apr 2007, Samuel Ortiz wrote:
> The patch below schedules irnet_flow_indication() asynchronously. Could
> you please give it a try (it builds, but I couldn't test it...) ? :
I'm afraid, your patch makes it worse - with my patch to ppp_generic it
worked 5 hours before Ir stopped, remai
This is a corner case where less than MSS sized new data thingie
is awaiting in the send queue. For F-RTO to work correctly, a
new data segment must be sent at certain point or F-RTO cannot
be used at all. RFC4138 allows overriding of Nagle at that
point.
Implementation uses frto_counter states 2
No new data is needed until the first ACK comes, so no need to
check for application limitedness until then.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/ipv4/tcp_input.c | 21 -
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/net/ipv4/tcp_input.c
On Wed, 11 Apr 2007, Jan Engelhardt wrote:
On Apr 11 2007 10:30, Esben Nielsen wrote:
On Tue, 10 Apr 2007, Jan Engelhardt wrote:
(Wow, not a single MODULE_AUTHOR line in drivers/net/arcnet/ ...)
ArcNet is old. Almost nobody is using it anymore. I used it at my
former job, since we used i
On Wed, 11 Apr 2007 12:52:28 +0400 "Yuriy N. Shkandybin" <[EMAIL PROTECTED]>
wrote:
>
>
> > (added netdev)
> >
> > On Wed, 11 Apr 2007 09:57:33 +0400 "Yuriy N. Shkandybin" <[EMAIL
> > PROTECTED]>
> > wrote:
> >
> >> I've tested 2.6.21-rc6-mm1
> >> Linux vpn1 2.6.21-rc6-mm1 #4 SMP Wed Apr 11
On Tue, 10 Apr 2007, David Miller wrote:
> As the merge window approaches I've made a decision about how to
> handle the TCP RB-Tree work since it's getting really close.
>
> First, I'm going to rebase the net-2.6.22 tree after making a quick
> run through my patch backlog looking for low hanging
(added netdev)
On Wed, 11 Apr 2007 09:57:33 +0400 "Yuriy N. Shkandybin" <[EMAIL PROTECTED]>
wrote:
I've tested 2.6.21-rc6-mm1
Linux vpn1 2.6.21-rc6-mm1 #4 SMP Wed Apr 11 03:34:26 MSD 2007 x86_64
Intel(R) Pentium(R) D CPU 2.80GHz GenuineIntel GNU/Linux
warn appeares upon first pppoe conne
On Apr 11 2007 10:30, Esben Nielsen wrote:
> On Tue, 10 Apr 2007, Jan Engelhardt wrote:
>>
>> (Wow, not a single MODULE_AUTHOR line in drivers/net/arcnet/ ...)
>
> ArcNet is old. Almost nobody is using it anymore. I used it at my
> former job, since we used it as control network. A lot of compani
On Tue, 10 Apr 2007, Jan Engelhardt wrote:
(Wow, not a single MODULE_AUTHOR line in drivers/net/arcnet/ ...)
ArcNet is old. Almost nobody is using it anymore. I used it at my former
job, since we used it as control network. A lot of companies still does
quitely, but not in combination with
From: "Martin Schwidefsky" <[EMAIL PROTECTED]>
Date: Wed, 11 Apr 2007 10:15:42 +0200
> On 4/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Tue, 10 Apr 2007 22:11:01 -0700 (PDT) David Miller <[EMAIL PROTECTED]>
> > wrote:
> > I think this means that if CONFIG_32BIT=y, s390 networking gets
On 4/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Tue, 10 Apr 2007 22:11:01 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote:
I think this means that if CONFIG_32BIT=y, s390 networking gets the whizzy
assembly version and if CONFIG_32BIT=n, it gets to use the generic version.
Possibly th
Hi:
[NET]: Get rid of NETIF_F_INTERNAL_STATS
The recently added NETIF_F_INTERNAL_STATS isn't very useful. If the
device driver needs to set it then it can always override get_stats
instead. All existing drivers that have stats (which should be every
one) will override get_stats anyway. Those t
(added netdev)
On Wed, 11 Apr 2007 09:57:33 +0400 "Yuriy N. Shkandybin" <[EMAIL PROTECTED]>
wrote:
> I've tested 2.6.21-rc6-mm1
> Linux vpn1 2.6.21-rc6-mm1 #4 SMP Wed Apr 11 03:34:26 MSD 2007 x86_64
> Intel(R) Pentium(R) D CPU 2.80GHz GenuineIntel GNU/Linux
>
> warn appeares upon first pppoe
83 matches
Mail list logo
