| Francois Romieu | [PATCH] r8169: revert part of 6dccd16b7c2703e8bbf8bca62b5cf2...
The 8169/8110SC currently announces itself as:
[...]
eth0: RTL8169sc/8110sc at 0x........, ..:..:..:..:..:.., XID 18000000 IRQ ..
^^^^^^^^
It uses RTL_GIGA_MAC_VER_05 and this part of the changeset can cut
its performance by a factor of 2~2.5 as reported by Timo.
(the driver includes code just before the hunk to write the ChipCmd
register when mac_version == RTL_GIGA_MAC_VER_0[1-4])
Signed-off-by: Francois Romieu <romieu@fr.zoreil.c...
| Oct 3, 6:42 pm 2007 |
| Alexey Dobriyan | [PATCH] Fix rose.ko oops on unload
Quick'n'dirty fix to 100% oops on "rmmod rose". Do you want me to
properly unwind everything before .24?
-----------
Commit a3d384029aa304f8f3f5355d35f0ae274454f7cd aka
"[AX.25]: Fix unchecked rose_add_loopback_neigh uses"
transformed rose_loopback_neigh var into statically allocated one.
However, on unload it will be kfree's which can't work.
Steps to reproduce:
modprobe rose
rmmod rose
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000008
printing eip:
c014...
| Oct 3, 2:54 pm 2007 |
| Jeff Garzik |
| Oct 3, 3:04 pm 2007 |
| Alexey Dobriyan |
| Oct 3, 3:21 pm 2007 |
| Jeff Garzik | [git patches] net driver fixes
sky2 is really the only important fix, the others are trivial.
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/sky2.c | 3 ---
drivers/net/wireless/bcm43xx/bcm43xx_wx.c | 2 +-
net/ieee80211/softmac/ieee80211softmac_wx.c | 2 +-
3 files changed, 2 insertions(+), 5 deletions(-)
Joe Perches (1):
bcm43xx: Correct printk with ...
| Oct 3, 2:40 pm 2007 |
| Jeff Garzik | [git patches] net driver updates
Normally I wait a day or two between pushes, to queue up patches and
also to avoid annoying my upstream :) But this includes a couple fixes
I felt should be upstreamed sooner rather than later.
Please pull from 'upstream' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream
to receive the following updates:
Jeff Garzik (1):
drivers/net/qla3xxx: trim trailing whitespace
Olof Johansson (11):
pasemi_mac: basic error checking
pasemi_mac: ...
| Oct 3, 2:39 pm 2007 |
| David Miller |
| Oct 3, 6:33 pm 2007 |
| Jeff Garzik |
| Oct 3, 1:51 pm 2007 |
| Dave Jones | lockdep report from bonding.
Reported by a Fedora user this morning.
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: bond0: Adding slave eth0.
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
bonding: bond0: making interface eth0 the new active one.
bonding: bond0: enslaving eth0 as an active interface with an up link.
=================================
[ INFO: inconsistent lock state ]
2.6.23-0.214.rc8.git2.fc...
| Oct 3, 1:05 pm 2007 |
| Andy Gospodarek | Re: lockdep report from bonding.
This isn't surprising and rears it's head every once in a while. It
probably becomes more apparent on faster, multiprocessor systems. The
big bonding-workqueue conversion patch that Jay and I have been testing
for a while should resolve this one too (since it moves the monitoring
out of softirq context *and* it switches the hashtbl locks to _bh ones
along with a bunch of other changes).
-
| Oct 3, 4:50 pm 2007 |
| Timur Tabi | [PATCH v4] qe: miscellaneous code improvements and fixes to ...
This patch makes numerous miscellaneous code improvements to the QE library.
1. Remove struct ucc_common and merge ucc_init_guemr() into ucc_set_type()
(every caller of ucc_init_guemr() also calls ucc_set_type()). Modify all
callers of ucc_set_type() accordingly.
2. Remove the unused enum ucc_pram_initial_offset.
3. Refactor qe_setbrg(), also implement work-around for errata QE_General4.
4. Several printk() calls were missing the terminating \n.
5. Add __iomem where needed, and chang...
| Oct 3, 12:34 pm 2007 |
| Stephen Hemminger |
| Oct 3, 12:44 pm 2007 |
| Timur Tabi | Re: [PATCH v4] qe: miscellaneous code improvements and fixes...
That would be too difficult. Some of the changes are single lines, and this
patch has already been approved -- I just cross-posted to netdev because I
made a few ucc_geth changes that can't be docoupled from the powerpc changes.
A series of 18 patches would just be convoluted.
--
Timur Tabi
Linux Kernel Developer @ Freescale
-
| Oct 3, 2:00 pm 2007 |
| Kumar Gala |
| Oct 3, 6:41 pm 2007 |
| Peter Zijlstra | [PATCH] net: fix race in process_backlog
Subject: net: fix race in process_backlog
The recent NAPI rework (4fa57c9ea9f36f9ca852f3a88ca5d2f1aebbc960)
introduced a race between netif_rx() and process_backlog() which
resulted in softirq processing to drop dead.
netif_rx() process_backlog()
irq_disable();
skb = __skb_dequeue();
irq_enable();
irq_disable();
__skb_queue_tail();
napi_schedule();
irq_enable();
if (!skb)
napi_complete(); <-- oops!
we cleared the napi bit, even though there is data to process....
| Oct 3, 11:44 am 2007 |
| David Miller |
| Oct 3, 5:58 pm 2007 |
| Stephen Hemminger | Re: [PATCH] net: fix race in process_backlog
On Wed, 03 Oct 2007 14:58:07 -0700 (PDT)
This looks like a better fix. the irq_enable is needed in both cases.
--- a/net/core/dev.c 2007-09-27 07:19:10.000000000 -0700
+++ b/net/core/dev.c 2007-10-03 15:03:54.000000000 -0700
@@ -2077,12 +2077,14 @@ static int process_backlog(struct napi_s
local_irq_disable();
skb = __skb_dequeue(&queue->input_pkt_queue);
- local_irq_enable();
if (!skb) {
- napi_complete(napi);
+ __napi_complete(napi);
+ local_irq_enable();
break...
| Oct 3, 6:05 pm 2007 |
| David Miller |
| Oct 3, 7:39 pm 2007 |
| Stephen Hemminger |
| Oct 3, 12:15 pm 2007 |
| Ilpo Järvinen | [PATCH net-2.6.24 0/3]: More TCP fixes
Hi Dave,
Sacktag fastpath_cnt_hint seems to be very tricky to get right...
I suppose this one fixes Cedric's case. I cannot say for sure
until there is something more definite indication of
tcp_retrans_try_collapse origin than what the simple late WARN_ON
gave for us. ...Especially since it's non-trivial to have skb
hint "correctly" positioned in the write_queue while still ending
up calling that function. However, considering how difficult it
seems to be for Cedric to reproduce, it might well...
| Oct 3, 7:00 am 2007 |
| Cedric Le Goater |
| Oct 3, 7:58 am 2007 |
| Ilpo Järvinen |
| Oct 3, 8:34 am 2007 |
| Cedric Le Goater |
| Oct 3, 8:48 am 2007 |
| Ilpo Järvinen |
| Oct 3, 9:19 am 2007 |
| Cedric Le Goater | Re: [PATCH net-2.6.24 0/3]: More TCP fixes
I have 2 spare nodes so i'll run both. 1) is on already without any issues
i'm just compiling 2)
I usually work on -mm, so what would be interesting for me is to have what you
need in net-2.6.24 which is getting pulled in -mm by andrew. then, if you need
an extra patch for verbosity, that's fine, i'll include it in my usual patchset.
Cheers,
-
| Oct 3, 10:05 am 2007 |
| Ilpo Järvinen |
| Oct 3, 10:22 am 2007 |
| Cedric Le Goater | Re: [PATCH net-2.6.24 0/3]: More TCP fixes
Below are the messages I got on 2) right after running ketchup (which does
a wget www.kernel.org)
He, you might have solved it with 1). If not, I'm keeping the hardware for
you.
Cheers,
C.
WARNING: at /home/legoater/linux/2.6.23-rc8-mm2-tcp_fastretrans/net/ipv4/tcp_ipv4.c:193 tcp_verify_fackets()
Call Trace:
<IRQ> [<ffffffff8041aa86>] tcp_verify_fackets+0x119/0x237
[<ffffffff80416e57>] tcp_fragment+0x468/0x4b8
[<ffffffff804184a5>] tcp_retransmit_skb+0x...
| Oct 3, 10:58 am 2007 |
| Cedric Le Goater | Re: [PATCH net-2.6.24 0/3]: More TCP fixes
bummer, I got this one on 1) :(
C.
WARNING: at /home/legoater/linux/net-2.6.24.git/net/ipv4/tcp_input.c:2325 tcp_fastretrans_alert()
Call Trace:
<IRQ> [<ffffffff8022ddb6>] __wake_up+0x1f/0x4c
[<ffffffff803fd9d3>] tcp_ack+0xcee/0x18ac
[<ffffffff80400764>] tcp_rcv_established+0x61f/0x6df
[<ffffffff8024e8d8>] __lock_acquire+0x8a1/0xf1b
[<ffffffff8040795b>] tcp_v4_do_rcv+0x3e/0x394
[<ffffffff804082d5>] tcp_v4_rcv+0x624/0x9b1
[<ffffffff803ecf...
| Oct 3, 11:12 am 2007 |
| Cedric Le Goater | Re: [PATCH net-2.6.24 0/3]: More TCP fixes
and a second run of ketchup gave the following.
cheers,
C.
WARNING: at /home/legoater/linux/2.6.23-rc8-mm2-tcp_fastretrans/net/ipv4/tcp_ipv4.c:193 tcp_verify_fackets()
Call Trace:
<IRQ> [<ffffffff8041aa86>] tcp_verify_fackets+0x119/0x237
[<ffffffff80416e57>] tcp_fragment+0x468/0x4b8
[<ffffffff804184a5>] tcp_retransmit_skb+0xcf/0x2f4
[<ffffffff8041878d>] tcp_xmit_retransmit_queue+0xc3/0x31e
[<ffffffff8041220a>] tcp_fastretrans_alert+0xb36/0xb43
[...
| Oct 3, 10:59 am 2007 |
| Ilpo Järvinen | [PATCH 1/3] [TCP]: Fix two off-by-one errors in fackets_out ...
1) Passing wrong skb to tcp_adjust_fackets_out could corrupt
fastpath_cnt_hint as tcp_skb_pcount(next_skb) is not included
to it if hint points exactly to the next_skb (it's lagging
behind, see sacktag).
2) When fastpath_skb_hint is put backwards to avoid dangling
skb reference, the skb's pcount must also be removed from count
(not included like above).
Reported by Cedric Le Goater <legoater@free.fr>
Signed-off-by: Ilpo J
| Oct 3, 7:00 am 2007 |
| Ilpo Järvinen |
| Oct 3, 7:00 am 2007 |
| Ilpo Järvinen |
| Oct 3, 7:00 am 2007 |
| David Miller | net-2.6.24 plans
I'm a bit behind after investigating the TCP performance issues that
turned out to be HW specific problems. It's a bit of a
dissapointment, I thought maybe there was a cool bug to fix in TCP :-)
Anyways, that means there are patches backlogged in my inbox and it is
also about time to do the hopefully last rebase of the net-2.6.24
tree.
I merged in Jeff Garzik's and John Linville's latest and I'm running
the current tree on my workstation most of today with good results so
far.
Linus should...
| Oct 3, 5:36 am 2007 |
| Sonny | kernel 2.4 vs 2.6 Traffic Controller performance
Hello
This is a repost, there seems to have a misunderstanding before.
I hope this is the right place to ask this. Does any know if there is a
substantial difference in the performance of the traffic controller
between kernel 2.4 and 2.6. We tested it using 1 iperf server and use
250 and 500 clients, altering the burst.
This is the set-up:
iperf client - router (w/ traffic controller) - iperf server
We use the top command inside the router to check the idle time of our
router to see this. Th...
| Oct 3, 2:14 am 2007 |
| Eric Dumazet | Re: kernel 2.4 vs 2.6 Traffic Controller performance
Hi Sonny
I am not sure what you are asking here. 65-70% idle time (or 60-65%) is fine.
2.6 is also not very meaningfull, there are a lot of changes between 2.6.0 and
2.6.23 :)
Why should you upgrade kernel ?
What bandwidth do you handle ?
What kind of platform is it ? (a new kernel wont help much if its a real old
machine, or old NICs)
You seem to have some bandwidth problem but focus on cpu affairs...
-
| Oct 3, 3:00 am 2007 |
| Sonny | Re: kernel 2.4 vs 2.6 Traffic Controller performance
Bandwidth is not a problem, we can get 10mbps without a hitch. But we
would like to know the scalability on the CPU vs the number of
clients. So far, for both kernels, we're getting 50% CPU utilization
using 500 clients and 384 burst kbps each.
-
| Oct 3, 4:31 am 2007 |
| John W. Linville | Re: Please pull 'upstream-davem' branch of wireless-2.6
No, in fact I'm quite conscious of that. I follow a procedure
identical to what you outlined. I even leave my 'master-davem' branch
available as a reference, and create the initial 'upstream-davem'
branch as a checkout from it. :-)
As an experiment, I cloned your current tree (which has the patches
applied already, thanks!) and created a branch which backed-out the
patches from me you had already applied by hand. I then did a pull
from my tree, and the results were quite clean.
[linville]:...
| Oct 3, 10:10 am 2007 |
| David Miller |
| Oct 3, 5:52 pm 2007 |
| Jeff Garzik |
| Oct 3, 1:39 pm 2007 |
| Jeff Garzik |
| Oct 3, 1:39 pm 2007 |
| Bill Davidsen | Re: [PATCH] sky2: jumbo frame regression fix
Have you verified that you are actually getting jumbo packets out of the
NIC? I had one machine which did standard packets silently using sky2
and jumbo using sk98lin. I was looking for something else with tcpdump
and got one of those WTF moments when I saw all the tiny packets.
--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
-
| Oct 3, 2:04 pm 2007 |
| Ian Kumlien | Re: [PATCH] sky2: jumbo frame regression fix
20:27:06.542461 IP pi.local > blue.local: ICMP echo request, id 27173, seq =
42, length 8008
20:27:06.543136 IP blue.local > pi.local: ICMP echo reply, id 27173, seq 42=
, length 8008
That should solve it for us, right? =3D)
--=20
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
| Oct 3, 2:28 pm 2007 |
| Stephen Hemminger | Re: [PATCH] sky2: jumbo frame regression fix
On Wed, 03 Oct 2007 03:34:34 +0200
Does the workaround (forced reset work). Ian, you are the first person to
report triggering it. I haven't found a way to make it happen.
What combination of flow control and speeds are you using?
--
Stephen Hemminger <shemminger@linux-foundation.org>
-
| Oct 3, 12:59 am 2007 |
| iank |
| Oct 3, 4:29 am 2007 |
| Ian Kumlien | Re: [PATCH] sky2: jumbo frame regression fix
Yes it works, it's the problem i had all along =3D)
As to how to make it happen thats a bit harder...
To me it seems like it's a combination of several connections and
somewhat high bandwidth but you have to send data for it to happen...
To me it usually happens when seeding files via Bittorrent, but it seems
like it has to be somewhat special circumstances to actually trigger it.
I use jumbo frames, my lan is gigabit, to my firewall. From the firewall
it's common 1500 mtu 100mbit and i doubt...
| Oct 3, 3:37 am 2007 |
| Stephen Hemminger |
| Oct 3, 12:53 am 2007 |
| Jeff Garzik |
| Oct 3, 12:58 am 2007 |
| Jeff Garzik |
| Oct 3, 1:47 pm 2007 |
| Olof Johansson | [PATCH RESEND] [11/11] pasemi_mac: enable iommu support
pasemi_mac: enable iommu support
Enable IOMMU support for pasemi_mac, but avoid using it on non-partitioned
systems for performance reasons.
The user can override this by selecting the PPC_PASEMI_IOMMU_DMA_FORCE
configuration option.
Signed-off-by: Olof Johansson <olof@lixom.net>
---
Oops! Here's the real copy.
-Olof
Index: k.org/arch/powerpc/platforms/pasemi/iommu.c
===================================================================
--- k.org.orig/arch/powerpc/platforms...
| Oct 3, 2:03 pm 2007 |
| Jeff Garzik |
| Oct 3, 2:19 pm 2007 |
