is full, but only tcp_v[46]_syn_recv_sock increments some
mib stats for dropped connection requests.
Is that deliberate, or is that a hole in the stats?
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Sridhar Samudrala wrote:
On Mon, 2007-09-10 at 11:42 -0700, Rick Jones wrote:
I've been digging around to see about inducing /proc/net/tcp to show
some interesting things for listen sockets (eg backlog depth, its max,
and dropped connection requests).
backlog depth(acceptq length
Return some useful information such as the maximum listen backlog and
the current listen backlog in the tcp_info structure and have that
match what one can see in /proc/net/tcp and /proc/net/tcp6.
Signed-off-by: Rick Jones [EMAIL PROTECTED]
---
diff -r bdcdd0e1ee9d Documentation/networking
hit the intermediate device out of
order and so stay that way across the GbE link.
Before I go and patch-out that text I thought I'd double check.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
That said, it's certainly plausible that, for a given set of N
ethernets all enslaved to a single bonding balance-rr, the individual
ethernets could get out of sync, as it were (e.g., one running a fuller
tx ring, and thus running behind the others).
That is the scenario of which I was
Stephen Hemminger wrote:
On Tue, 4 Sep 2007 13:20:47 -0700 (PDT)
Rick Jones [EMAIL PROTECTED] wrote:
Build upon David Miller's initial patches to set the per-route rto_min
so users can specify the rto_min in the same units (milliseconds) in
which they are displayed. This is desirable because
to respond to an ARP request for any of the IP's assigned to any
of the interfaces.
worse, it continues to do it after unconfiguring
eth0:1 and eth0.
As in simply marking it down?
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
Stephen Hemminger wrote:
On Tue, 4 Sep 2007 13:20:47 -0700 (PDT)
Rick Jones [EMAIL PROTECTED] wrote:
Build upon David Miller's initial patches to set the per-route rto_min
so users can specify the rto_min in the same units (milliseconds) in
which they are displayed. This is desirable because
system to system would be error prone.
Signed-off-by: Rick Jones [EMAIL PROTECTED]
---
*** ./lib/utils.c.orig 2007-09-04 13:11:01.0 -0700
--- ./lib/utils.c 2007-09-04 13:06:11.0 -0700
***
*** 61,66
--- 61,141
return 0;
}
+ /* liberally lifted
Stephen Hemminger wrote:
On Thu, 30 Aug 2007 18:09:17 -0700
Rick Jones [EMAIL PROTECTED] wrote:
While messing about with sysctl_tcp_rto_min I went back and forth a
bit as to whether there should have been bounds checking (as did some of
the folks who did some internal review for me
John Heffner wrote:
Rick Jones wrote:
Like I said the consumers of this are a triffle well, anxious :)
Just curious, did you or this customer try with F-RTO enabled? Or is
this case you're dealing with truly hopeless?
F-RTO was mentioned to the customer and I'm awaiting their response
David Miller wrote:
From: Rick Jones [EMAIL PROTECTED]
Date: Thu, 30 Aug 2007 18:07:13 -0700
Anyhow, I'll try grubbing around the source code (already doing that to
see about writing a pet tcp cong module) but if pointers to the likely
relevant files were available I could try to help thrash
I managed to find iproute2 sources (they were debian lenny/testing
2.6.20-1) and applied the patch, and figured-out how to add a host route
back to one of my systems. I then did a change to set rto_min to 300.
I started a tcpdump and then a netperf, and then forces some
retransmissions the
David Miller wrote:
From: Rick Jones [EMAIL PROTECTED]
Date: Fri, 31 Aug 2007 13:59:50 -0700
ip is at tcp_rto_min+0x20/0x40
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 1ee7212..bbad2cd 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -560,7 +560,7
Krishna Kumar2 wrote:
Hi Rick,
From: Rick Jones [EMAIL PROTECTED]
The trace I've been sent shows clean RTTs ranging from ~200
milliseconds
to ~7000 milliseconds.
Thanks for the info.
It's pretty easy to generate examples where we might have some sockets
talking over interfaces
Enable configuration of the minimum TCP Retransmission Timeout via
a new sysctl tcp_rto_min to help those who's networks (eg cellular)
have quite variable RTTs avoid spurrious RTOs.
Signed-off-by: Rick Jones [EMAIL PROTECTED]
Signed-off-by: Lamont Jones [EMAIL PROTECTED]
---
diff -r 06d7322848a3
David Miller wrote:
From: Rick Jones [EMAIL PROTECTED]
Date: Thu, 30 Aug 2007 17:09:04 -0700 (PDT)
Enable configuration of the minimum TCP Retransmission Timeout via
a new sysctl tcp_rto_min to help those who's networks (eg cellular)
have quite variable RTTs avoid spurrious RTOs.
Signed-off
networking sysctls?
rick jones
-
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
sort of call-back to TCP or the like.
If this failover is out in the middle of the cloud the only way to get a
notification back to TCP would be by sending it a packet of some sort
and I don't see that happening.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev
.
rick jones
-
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
I am sure you can use CTL_UNNUMBERED instead of adding yet another
sysctl value, as advised in include/linux/sysctl.h
** For new interfaces unless you really need a binary number
** please use CTL_UNNUMBERED.
fair enough. i was just repeating past behaviour :)
rick jones
David Miller wrote:
From: Ian McDonald [EMAIL PROTECTED]
Date: Thu, 30 Aug 2007 09:32:38 +1200
So I'm suspecting that the default should be changed to 1000 to match
the RFC which would solve this issue. I note that the RFC is a SHOULD
rather than a MUST. I had a quick look around and not sure
From what I've seen thusfar, the issue isn't so much actual loss, but
very variable RTTs leading to spurrious RTOs.
rick jones
-
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
All of this seems to suggest that the RTO calculation is wrong.
That is a possiblity. Or at least could be enhanced.
It seems that packets in this network can be delayed several orders of
magnitude longer than the usual round trip as measured by TCP.
What exactly causes such a huge delay?
David Miller wrote:
From: Rick Jones [EMAIL PROTECTED]
The trace I've been sent shows clean RTTs ranging from ~200 milliseconds
to ~7000 milliseconds.
Thanks for the info.
It's pretty easy to generate examples where we might have some sockets
talking over interfaces on such a network
definition of finite?
rick jones
-
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
I don't even understand why this needs to be discussed to be honest
with you :-)
Just my (possibly frustrating :) habit of asking questions which help
further my understanding of the code :)
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message
on the receiver. I don't know if it can account for all the
difference you see.
I had completely forgotten these stretch ACK and ucopy issues.
ISTR that LRO will induce stretch ACKs as well. Not that I dislike fewer ACKs
mind you... :)
rick jones
-
To unsubscribe from this list: send the line
A current hot topic of research is reducing the number of ACK's to make TCP
work better over asymmetric links like 3G.
Oy. People running Solaris and HP-UX have been researching ACK reductions
since 1997 if not earlier.
rick jones
-
To unsubscribe from this list: send the line unsubscribe
a request, wait for reply, send next request, etc etc
etc is a rather common application behaviour afterall.
rick jones
-
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
Bill Fink wrote:
On Thu, 23 Aug 2007, Rick Jones wrote:
jamal wrote:
[TSO already passed - iirc, it has been
demostranted to really not add much to throughput (cant improve much
over closeness to wire speed) but improve CPU utilization].
In the one gig space sure, but in the 10 Gig space
.
rick jones
Is the current behaviour intended?
Regards,
Laszlo Attila Toth
-
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
-
To unsubscribe from this list: send
jones
-
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
stuff I posted recently) being rather worse with TSO enabled than with it
disabled?
rick jones
-
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
handwaving terms, TSO increased the per-transaction service demand
by something along the lines of (23.27 - 17.67)/17.67 or ~30% and the
transaction rate decreased by ~6%.
rick jones
bitrate blindless is a constant concern
-
To unsubscribe from this list: send the line unsubscribe netdev
A Fedora users reported this against our 2.6.23-rc3 build
Dave
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
Ethernet Channel Bonding Driver: v3.1.3 (June 13, 2007)
bonding: MII link monitoring set to 100 ms
ADDRCONF(NETDEV_UP): bond0: link is not ready
bonding:
not during a netperf TCP_RR test.
Does anyone else see this? To try to eliminate netperf demo mode I re-ran
without it and got the same end results.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
of bugs seemed easy to automate. This is one of them
I found where it looks like this semicolon is not valid.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
Yikes! Makes you want to audit the entire tree for these
things :-)))
Indeed. Here's another one.
Signed-off-by: Dave Jones
or heck, even elke if one wanted
to be a triffle playful would certainly help distinguish this driver
from its grandfather.
rick jones
-
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
change.
rick jones
-
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
is ignored.
(i.e. a list of 5 strings is returned, but bit 24 is set)
Is that to enable hidden bits? If not I'd think that emitting some
sort of UNKNOWN_FLAG might help flush-out little oopses like
forgetting a string.
rick jones
-
To unsubscribe from this list: send the line unsubscribe
jones
-
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
that
doesn't break the bitbank it does get rather close.
rick jones
-
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
Thanks for the feedback Rick. We haven't used the netperf trunk. The
person who actually got these numbers will be trying the netperf trunk
little later and we will post the results..
Just in case someone has top-of-trunk worries, the basic single-stream,
bidirectional stuff is in the 2.4.3
0 AF_INET6 : +/-2.5% @ 99% conf.
Cool - it establishes the data connection just fine.
To further demonstrate my ignorance :) is that %n suffix something one might
expect in most/all getaddrinfo()'s or is that unique to the one in Linux?
rick jones
-
To unsubscribe from this list: send
too soon - while it got me past my EINVAL, the connection
establishement timed-out. Either I picked the wrong value for n, or I may yet
need to make some tweaks to netperf.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED
as
computed average latency. That is also in top of trunk, otherwise, for 2.4.3
you can skip that and do the math to conver to megabits/s yourself and not get
all the other derived values.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
might be expected to remain in the future, or is it
something which might just go away? That will have an effect on netperf future
development.
thanks,
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info
David Miller wrote:
From: Rick Jones [EMAIL PROTECTED]
Date: Fri, 13 Jul 2007 09:55:10 -0700
Fine, but so? I suspect the point of the patch is to provide a
lower cap on the accumulated backoff so data starts flowing over the
connection within that lower cap once the link is
restored/failed
Ilpo Järvinen wrote:
On Thu, 12 Jul 2007, Rick Jones wrote:
One question is why the RTO gets so large that it limits failover?
If Linux TCP is working correctly, RTO should be srtt + 2*rttvar
So either there is a huge srtt or variance, or something is going
wrong with RTT estimation
that pretty much sum it up?
rick jones
-
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
, that would cause RTO to be 1second.
I suspect that what is happening here is that a link goes down in a
trunk somewhere for some number of seconds, resulting in a given TCP
segment being retransmitted several times, with the doubling of the RTO
each time.
rick jones
-
To unsubscribe from
, the general answer is that the device failover time
is fixed, and the application layer time is similarly constrained by
end-user expectation/requirement. Often as not, layer 8 and 9 issues
tend to dominate and expect to trump (in this case layer 4 issues).
rick jones
-
To unsubscribe from this list
the timing ever so slightly
and you can have a rather larger change in throughput. That could be
dealt-with either with the larger send sizes mentioned above, or by
adding a test-specific -D option to set TCP_NODELAY.
happy benchmarking,
rick jones
-
To unsubscribe from this list: send the line
? nah) to e1000 to get e1k, which if you look at it quickly
enough looks like elk. OK, that's half in jest, but only half. I may
be wrong, but I don't think I've seen anyone shortening the current
e1000 to e1k?
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev
Chris Snook wrote:
Rick Jones wrote:
It seems that every driver, when providing support for ethtool -S
functionality, has considerable lattitude when it comes to the stats
provided. Clearly this is very nice for the driver writer(s) as it
allows them to provide whatever stats they feel
the drivers stick
stats in multiple places? Or are we back to wanting drivers to have a
common set of stats they keep?
rick jones
unafraid to show his ignorance of how things work, and how :)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
, and I've just not
seen it?
rick jones
-
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
Evgeniy Polyakov wrote:
On Thu, Jun 21, 2007 at 02:00:07PM -0700, Rick Jones ([EMAIL PROTECTED]) wrote:
Simple test included test - desktop and vice versa traffic with 128 and
4096 block size in netperf-2.4.3 setup.
Is that in conjunction with setting the test-specific -D to set
TCP_NODELAY
-machine-local link failover.
rick jones
-
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
Robert Iakobashvili wrote:
Hi,
On Sun, 24 Jun 2007 12:20:01 -0500 David Jones [EMAIL PROTECTED]
wrote:
I am trying to add multiple IP addresses ( v6 ) to my FC7 box on eth0.
But I am hitting a max limit of 4000 IP address . Seems like there
is a
limiting variable in linux kernel (which
intervals weren't hit since the relative
batching of 128byte sends into larger segments is something of a race.
rick jones
-
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
I'm starting to wonder how a multi-queue NIC differs from a bunch of
bonded single-queue NICs, and if there is leverage opportunity there.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
to calculate service
demand by hand. Sum the throughput as KB/s, convert the CPU util and
number of CPUs to a microseconds of CPU consumed per second and divide
to get microseconds per KB for the aggregate.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body
with that a little
would be to increase SO_SNDBUF in netperf with the -s option. That at
least is something I did back in 2.4 days
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
jamal wrote:
On Fri, 2007-08-06 at 10:27 -0700, Rick Jones wrote:
[..]
you cannot take the netperf service demand directly - each netperf is
calculating assuming that it is the only thing running on the system.
It then ass-u-me-s that the CPU util it measured was all for its work
scc_rxint doesn't call this function at all.
http://bugzilla.kernel.org/show_bug.cgi?id=8146
Signed-off-by: Dave Jones [EMAIL PROTECTED]
diff --git a/drivers/net/hamradio/scc.c b/drivers/net/hamradio/scc.c
index 6fdaad5..30bed2a 100644
--- a/drivers/net/hamradio/scc.c
+++ b/drivers/net/hamradio
http://bugzilla.kernel.org/show_bug.cgi?id=8160
Signed-off-by: Dave Jones [EMAIL PROTECTED]
diff --git a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c
index 25b75b6..b670b97 100644
--- a/drivers/net/via-velocity.c
+++ b/drivers/net/via-velocity.c
@@ -1562,7 +1562,7 @@ static void
RX queues - yes, I can see; TX queues, it doesnt make sense to put
different rings on different CPUs.
To what extent might that preclude some cachelines bouncing hither and
yon between the CPUs?
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body
On Wed, Jun 06, 2007 at 06:04:21PM -0700, Andrew Morton wrote:
There _should_ be some #ifdeffable thing which is being passed to cpp when
we run sparse (but I'm not sure what it is).
#ifdef __CHECKER__
(See include/linux/compiler.h, this is how we implement __user friends)
Dave
suppose it could be SCTP)
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, May 21, 2007 at 02:51:35PM -0700, Auke Kok wrote:
Herbert Xu wrote:
netif_poll_enable can only be called if you've previously called
netif_poll_disable. Otherwise a poll might already be in action
and you may get a crash like this.
Removing the call to netif_poll_enable in
On Mon, May 21, 2007 at 05:58:27PM -0700, Kok, Auke wrote:
This probably doesn't solve the latter bug.
The code you reference isn't there in the kernel tested in that bug
(2.6.21) In 2.6.21, netif_poll_enable is only called from
e1000_up(), not e1000_open()
Yes we need a
degrade TCP performance when packet losses start to
occur. With limited slow-start, TCP increments the congestion window by at most
tcp_max_ssthresh/2 segments per RTT when the congestion window is is above
tcp_max_ssthresh.
rick jones
as an asside, tcp_max_ssthresh sounds like the maximum
As mentioned in http://bugzilla.kernel.org/show_bug.cgi?id=5015
The helptext implies that this is on by default.
This may be true on some distros (Fedora/RHEL have it enabled
in /etc/sysctl.conf), but the kernel defaults to it off.
Signed-off-by: Dave Jones [EMAIL PROTECTED]
diff --git a/net
On 16 May 2007, at 10:41, Lennert Buytenhek wrote:
Making a driver work in both modes
of operation is generally not just an issue of adding a couple of
be32_to_cpu()s in the right places.
While this comment is technically correct, Christian's driver
achieves endian agnostic operation with
there times when it does indeed mean that someone should be
looking into it?
rick jones
-
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
Jeff Garzik wrote:
Rick Jones wrote:
But that is rather incidental isn't it? Would some sort of system
health monitor be likely to be checking that for interrupt flavors? And
Well, that's where the information is exported in a standard way. I
hope you're not suggesting that a system
On Wed, May 16, 2007 at 02:33:18PM -0700, - wrote:
Kernel version 2.6.20.4 works. What I'm experiencing is a kernel panic as
soon as the first received packet comes in via the sis900 ethernet
interface. The machine is locked up and part of the kernel panic message
is lost as it has
,0004
hpcpc106:~/s2io-2.0.19-8893# cat /proc/interrupts | grep 69
69: 0 0 0 0 PCI-MSI
eth2:MSI-X-6-RX
It would be nice if this could find its way into the kernel at some point -
2.6.23 or 2.6.24 perhaps?
rick jones
-Andi
Report the pending irq
61000 than 63355. They both
have that sign-bit set.
While it is security through obscurity having the same default port range as
other platforms would I suppose make it just a little bit more difficult for
fingerprinting.
random thoughts,
rick jones
Solaris:
# ndd /dev/tcp
Note that the high-order bit is set for all ports above 32768, so this
dragon would be stepped on pretty badly by Linux's default (and
indeed, the default for most OS's).
However, by the very top, I think he was referring to the range
61000-65535, not all ports from 32768 up. Alan Cox clarified
small sends, which suggests that they
would be coalesced either implicitly by the Nagle algorithm or explicitly with
TCP_CORK no?
rick jones
-
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
Vlad Yasevich wrote:
Rick Jones wrote:
It is the reverse - GSO will segment one super-packet just before calling
the driver so that the stack is traversed only once. In my case, I am
trying to send out multiple skbs, possibly small packets, in one shot.
GSO will not help for small packets
and then dropping the
others, thus transmitting IP datagrams which had no hope of being reassembled
into anything other than frankengrams.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
jamal wrote:
The discussion seems to have steered into protocol coalescing.
My tests for example were related to forwarding and not specific
to any protocol.
Just the natural tendency of end-system types to think of end-system things
rather than router things.
rick jones
-
To unsubscribe
in the first place wouldn't one?
rick jones
-
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
promise no more old HP-UX stories for the
balance of the week :)
Taking some count of the list might be a triffle too complicated.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
, as a cache line miss is far
more expensive than a locked operation (if lock already in L1 cache of
course)
Might they not build on on top of the other?
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info
On 9 May 2007, at 15:22, David Acker wrote:
Big endian is the natural setup for the NPEs on this hardware
according to the intel documentation. Please don't stop this
driver from moving forward so that a few folks can run their
hardware in slow mode.
No-one is saying that this driver
On 8 May 2007, at 01:46, Krzysztof Halasa wrote:
Adds a driver for built-in IXP4xx hardware Queue Manager.
Signed-off-by: Krzysztof Halasa [EMAIL PROTECTED]
[snip]
diff --git a/arch/arm/mach-ixp4xx/ixp4xx_qmgr.c b/arch/arm/mach-
ixp4xx/ixp4xx_qmgr.c
new file mode 100644
index
], *tx_skb_tab[TX_DESCS];
+ struct desc *desc_tab; /* coherent */
+ u32 desc_tab_phys;
+ sync_serial_settings settings;
+ int id;
+ u8 hdlc_cfg;
+};
+
[snip]
Again, looking good.
Michael-Luke Jones
-
To unsubscribe from this list: send the line unsubscribe netdev
On 8 May 2007, at 09:26, Mikael Pettersson wrote:
On Tue, 8 May 2007 08:22:17 +0100, Michael-Luke Jones wrote:
AFAIK, it's a HW limitation of the IXP4xx NPEs, or
possibly Intel's microcode for them.
I run my IXP42x boxes big-endian and don't mind doing so.
/Mikael
*cough*
http
On 8 May 2007, at 09:48, Alexey Zaytsev wrote:
I was always curious, why do people want to run ixp4xx in LE mode?
What
are the benefits that overweight the obvious performance degradation?
Debian.
http://www.debian.org/ports/arm/
Michael-Luke
-
To unsubscribe from this list: send the line
Jones
PS: Please cc me on replies as I only subscribe to l-a-k.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On how topologically big a system has this resurrection of the PIO read been
tried so far?
rick jones
ever the paranoid :)
-
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
Michael Chan wrote:
On Mon, 2007-05-07 at 09:39 -0700, Rick Jones wrote:
On how topologically big a system has this resurrection of the PIO read been
tried so far?
If you're asking how much impact the read will have on performance, the
answer is that it will depend on whether you
[Added Lennert Buytenhek to CC list]
Hey again,
Code placement:
Queue Manager NPE code = arch/arm/mach-ixp4xx
WAN driver code = drivers/net/wan
Eth code = drivers/net/arm
Why would you want such placement?
Potential problems: header files would have to be moved to
include/asm-arm = headers
Folks -
Is it a bug, or a feature that after changing a device's smp_affinity via echo
N /proc/irq/M/smp_affinity that the new mask isn't visible via cat
/proc/irq/M/smp_affinity until after actual interrupts are taken?
rick jones
-
To unsubscribe from this list: send the line unsubscribe
Arjan van de Ven wrote:
On Mon, 2007-05-07 at 13:53 -0700, Rick Jones wrote:
Folks -
Is it a bug, or a feature that after changing a device's smp_affinity via echo
N /proc/irq/M/smp_affinity that the new mask isn't visible via cat
/proc/irq/M/smp_affinity until after actual interrupts
301 - 400 of 666 matches
Mail list logo
