Re: [ANNOUNCE] iproute2 2.6.14-051107
On 12/5/05, Stephen Hemminger [EMAIL PROTECTED] wrote: On Sun, 4 Dec 2005 17:17:24 -0200 Arnaldo Carvalho de Melo [EMAIL PROTECTED] wrote: Agreed, I was quite annoyed when this happened to me: [EMAIL PROTECTED] ~]# ip r s Object r is unknown, try ip help. [EMAIL PROTECTED] ~]# rpm -q iproute2 iproute2-ss050901-79426cl [EMAIL PROTECTED] ~]# When for years I enjoyed using it: [EMAIL PROTECTED] ~]# ip r s 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.4 metric 10 default via 192.168.1.2 dev eth0 [EMAIL PROTECTED] ~]# rpm -q iproute2 iproute2-2.6.10-2mdk [EMAIL PROTECTED] ~]# The old behaviour is back (in CVS). Thanks Stephen. - Arnaldo - 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
Re: Resend [PATCH netdev-2.6 2/8] e1000: Performance Enhancements
On Sat, 2005-03-12 at 14:58 -0700, Grant Grundler wrote: On Sat, Dec 03, 2005 at 02:37:59PM -0500, jamal wrote: On Sat, 2005-03-12 at 12:00 -0700, Grant Grundler wrote: On Sat, Dec 03, 2005 at 09:20:52AM -0500, jamal wrote: Ok, so you seem to be saying again that for case #b above, there is no harm in issuing the prefetch late since the CPU wont issue a second fetch for the address? Right. (When that's not true, add to cost of issueing a prefetch.) Can we verify if this is the case _always_ or it is the case of some architectures? It does seem like an obvious optimization .. TBH, I'm not interested in a fishing expedition right now. Dude, _I_ need to know ;- When someone presents a particular prefetch which is measurably hurting performance, then we can look at that implementation to see if the cache controller is issuing multiple requests for the same cacheline (or not). What Dave wants is reasonable - I am hoping that the Intel folks will get around to it first having blown my 2.5 drive; i still need to know the answer to the question ;- Counting on you. cheers, jamal - 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
Re: [RFC] ip / ifconfig redesign
On Sat, Dec 03, 2005 at 10:33:32AM -0800, Ben Greear wrote: Al Boldi wrote: Here specifically, ip/ifconfig is implemented upside-down requiring a link/dev to exist for an address to be defined, in effect containing layer 3 inside layer 2, when an address should be allowed to be defined w/o a link/dev much like an app is allowed to be defined w/o an address. [Removed lkml from CC list] You can add multiple virtual IP addresses to physical interfaces. It makes no sense to have an IP without any association to an interface in my opinion. Often, when you have multiple interfaces, you most definately want different IPs associated specifically with particular interfaces. Think about redundant paths, routers, firewalls, and such. The association between IP addresses and links is already a bit murky. Reference the arp_announce sysctl for what I mean. I recall Dave M. emphasizing on at least one occassion that IP addresses belong to the _box_, not to the link. I think Al B.'s idea merits some consideration. I definitely think we blur the distinctions between L2 and L3 a bit too much in places. Of course, patches would be helpful... John -- John W. Linville [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
Re: [RFC] ip / ifconfig redesign
John W. Linville wrote: SNIP Of course, patches would be helpful... /sbin/ipadd address #!/bin/sh ip addr add $1 dev lo /sbin/ipdel address #!/bin/sh ip addr del $1 dev lo /sbin/ipactivate address device #!/bin/sh ip addr add $1 dev $2 /sbin/ipdeactivate address device #!/bin/sh ip addr del $1 dev $2 There are your 'patches'. Add -6's to places for IPv6 versions. Greets, Jeroen signature.asc Description: OpenPGP digital signature
(fwd) Bug#341392: linux-2.6: kernel BUG at mm/slab.c:1807!
please take a look at belows BUG_ON()
at a quick glance didn't find a patch for that in git-commits-list.
belows kernel has all fixes from the latest 2.6.14.3 stable.
- Forwarded message from Frans Pop [EMAIL PROTECTED] -
Subject: Bug#341392: linux-2.6: kernel BUG at mm/slab.c:1807!
Date: Wed, 30 Nov 2005 13:14:02 +0100
From: Frans Pop [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Package: linux-2.6
Version: 2.6.14-4
Severity: serious
The following error happens on Debian Installer boot in vmware (386 kernel).
This problem was not present in -3.
The system does come up after the error, but it looks so basic (memory
management AFAICT) that I've set RC severity anyway.
Feel free to adjust if you disagree.
Cheers,
FJP
ACPI: Processor [CPU0] (supports 8 throttling states)
kmem_cache_create: duplicate cache UNIX
[ cut here ]
kernel BUG at mm/slab.c:1807!
invalid operand: [#1]
Modules linked in: unix thermal processor fan pcnet32 mii uhci_hcd usbcore
CPU:0
EIP:0060:[c013c552]Not tainted VLI
EFLAGS: 00010202 (2.6.14-2-386)
EIP is at kmem_cache_create+0x4ea/0x64c
eax: 002b ebx: c9c26b4c ecx: c02f8080 edx: 206b
esi: c0303829 edi: ca86fde9 ebp: c9c26980 esp: c988ff38
ds: 007b es: 007b ss: 0068
Process modprobe (pid: 1605, threadinfo=c988e000 task=c98c8a70)
Stack: c02ba8f8 ca86fde4 000a c9a957a0 c9c2699c ff80 0080 c000
0080 ca870080 ca86fd60 0804e154 ca86fde4 c02410d2 ca86fde4 015c
2000 ca804000 ca870080 0804e190 0804e154
Call Trace:
[c02410d2] proto_register+0x56/0x1b4
[ca804000] af_unix_init+0x0/0x5f [unix]
[ca80400d] af_unix_init+0xd/0x5f [unix]
[c012e8a1] sys_init_module+0x99/0x16c
[c01030dd] syscall_call+0x7/0xb
Code: c9 fc ff ff 55 e8 0f 0e 00 00 59 e9 a9 fd ff ff 90 ff 74 24 30 68 f8 a8
2b c0 e8 6e b3
fd ff ff 05 4c 16 39 c0 0f 8e cb 15 00 00 0f 0b 0f 07 0d a0 2b c0 58 5a e9
d7 fd ff ff b8
00 e0 ff ff 21
6usbcore: registered new driver usbkbd
drivers/usb/input/usbkbd.c: :USB HID Boot Protocol keyboard driver
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
- End forwarded message -
-
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
Re: Issue 0 WAS (Re: Oustanding issues WAS(IRe: Consensus? WAS(RFC 2863)
Am Donnerstag 01 Dezember 2005 13:48 schrieb Krzysztof Halasa: - kernel driver signals lower-level down - kernel driver signals lower-level up (dormant = 1) - slow userspace (in this case, could be a kernel module if strict serialization of all operational status changes isn't required) doesn't (yet) see the above events and sets fully operational? If the supplicant is able to set states, it should also be able look if new events have piled up on netlink. I'm aware this isn't perfect. For me, one important point is that driver and userspace do not interfere uncontrolled, so that we have no situation where both driver and userspace start setting operstate and in the end create some crazy value that no one is aware of. I think this goal is reached due to setting operstate from process context only and echo changes made by userspace back via netlink. We have also caught the situation when userspace is not able to run at all after a up-down-up transition. I'm more unhappy about the fact that a driver can (and could) do a netif_carrier_off()/-on() sequence too fast for the workqueue to follow. But changing this requires major surgery in netdev_state_change() and hey, I'm not a networking core guru. Look, you (I mean Thomas and Jamal, too) can ignore that problem (or problem), pretend it's fixed when it's not, exactly like you ignore existence of my patch. No one ignored your patch. I only plead guilty for willing to solve both your problem and userspace interaction. And I think we have reached a compromise that is acceptable for both. So no need for flaming. Stefan - 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
Re: [RFC] ip / ifconfig redesign
On Mon, Dec 05, 2005 at 09:01:00AM -0500, John W. Linville wrote: On Sat, Dec 03, 2005 at 10:33:32AM -0800, Ben Greear wrote: Al Boldi wrote: Here specifically, ip/ifconfig is implemented upside-down requiring a link/dev to exist for an address to be defined, in effect containing layer 3 inside layer 2, when an address should be allowed to be defined w/o a link/dev much like an app is allowed to be defined w/o an address. [Removed lkml from CC list] You can add multiple virtual IP addresses to physical interfaces. It makes no sense to have an IP without any association to an interface in my opinion. Often, when you have multiple interfaces, you most definately want different IPs associated specifically with particular interfaces. Think about redundant paths, routers, firewalls, and such. The association between IP addresses and links is already a bit murky. Reference the arp_announce sysctl for what I mean. I recall Dave M. emphasizing on at least one occassion that IP addresses belong to the _box_, not to the link. I think Al B.'s idea merits some consideration. I definitely think we blur the distinctions between L2 and L3 a bit too much in places. Of course, patches would be helpful... Precisely the case. It should be the case that a box response to an arp on *any* interface for *any* IP address known to the box. As for changing the behavior, I haven't seen a compelling reason to change it. IMHO, without a motivating case, we would be mucking about without a clear goal. - 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
Re: [RFC] ip / ifconfig redesign
Marc Singer wrote: On Mon, Dec 05, 2005 at 09:01:00AM -0500, John W. Linville wrote: On Sat, Dec 03, 2005 at 10:33:32AM -0800, Ben Greear wrote: SNIP The association between IP addresses and links is already a bit murky. Reference the arp_announce sysctl for what I mean. I recall Dave M. emphasizing on at least one occassion that IP addresses belong to the _box_, not to the link. Precisely the case. It should be the case that a box response to an arp on *any* interface for *any* IP address known to the box. Thus you have the following nice setup: 10.100.10.0/24 = 10Gbit streaming network 10.100.20.0/24 = 10mbit admin network 10.100.10.1 on eth0 10.100.20.1 on eth2 Then some idiot misconfigures his client box, putting 10.100.10.42/24 on the NIC that is supposed to be in the admin network only. Suddenly your 10mbit link is full because the arp's get answered on this link. I wonder how many RFC's it violates. An interface must only answer ARP's on the interface that it is configured on, not anything else. There is a low level of brokeness here already. When you have: eth0 = 10.100.10.1/24 eth1 = 192.168.1.1/24 default route towards 192.168.1.250, forwarding enabled. SMTP on 192.168.1.1. Now when a client from 10.100.10.5 contacts 192.168.1.1, the FORWARD chain of iptables is skipped. The packet directly comes into INPUT. Blocking based on the decision that it is actually being forwarded is impossible because of this, unless you do -i eth0 -d 192.168.1.1. Combine this with the above and you can suddenly access internal IP's when the firewall is configured correctly to block FORWARD's from the eth1 interface and you have an internal service on 10.100.10.1. You only have to find a way to be local on the external interface so that you can do arp's for internal IP's. It will be loved by pesky ISP's who limit people and disallow them to do NAT of course. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: Broadcom 43xx first results
On Sun, 04 Dec 2005 19:50:08 +0100, [EMAIL PROTECTED] wrote: The team is in the progress of writing a SoftwareMAC layer, which is needed for the bcm device. The SoftMAC is still very incomplete. So do not expect to do any fancy stuff like WPA or something line that with it. Why yet another attempt to write 802.11 stack? Sure, the one currently in the kernel is unusable and everybody knows about it. But why not to improve code opensourced by Devicescape some time ago instead of inventing the wheel again and again? Yes, I know that code is not perfect and needs a lot of work, but it is the best piece of code we have available now. And it _does_ support WPA and such - in fact, it is nearly complete. Please take a look at http://kernel.org/pub/linux/kernel/people/jbenc/ Thanks, -- Jiri Benc SUSE Labs - 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
Re: [RFC: -mm patch] drivers/net/wireless/hostap/hostap_main.c shouldn't #include C files
On Sun, Dec 04, 2005 at 06:14:09PM -0800, Jouni Malinen wrote: On Sat, Dec 03, 2005 at 01:23:09PM +0100, Adrian Bunk wrote: This patch contains an attempt to properly build hostap.o without #incude'ing C files. Looks good. However, I did not test this now since this did not apply to netdev-2.6 (it does not have hostap_main.c). Did the hostap.c to hostap_main.c rename go only to -mm? I would prefer to do this kind of changes in a single place and I thought netdev-2.6 would be that. I'm not following -mm tree at all and it would be easier to go through patches if they are against netdev-2.6 upstream branch. The hostap_main.c rename is in the git-netdev-all tree that gets pulled into -mm. I don't know the exact setup of Jeff's (Cc'ed) git trees. Jouni Malinen cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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
Re: Broadcom 43xx first results
Hi. On Mon, 2005-12-05 at 19:00 +0100, Jiri Benc wrote: Why yet another attempt to write 802.11 stack? Sure, the one currently in the kernel is unusable and everybody knows about it. But why not to improve code opensourced by Devicescape some time ago instead of inventing the wheel again and again? Or, in case there is some unknown objection to the mentioned code: use the 802.11 stack that comes along with MadWifi, which provides things like virtual interfaces (for multiple SSID support on one physical card) and WPA support. Although I'm a bit biased towards MadWifi, I'd second your suggestion to make use of the Devicescape code. The benefit of having a fully-blown 802.11 stack in the kernel that drivers can make use of has been discussed before, so I won't go into that yet again. Bye, Mike - 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
Re: Broadcom 43xx first results
Why yet another attempt to write 802.11 stack? Sure, the one currently in the kernel is unusable and everybody knows about it. But why not to improve code opensourced by Devicescape some time ago instead of inventing the wheel again and again? Yes, I know that code is not perfect and needs a lot of work, but it is the best piece of code we have available now. And it _does_ support WPA and such - in fact, it is nearly complete. Please take a look at http://kernel.org/pub/linux/kernel/people/jbenc/ We're not writing an entire stack. We're writing a layer that sits in between the current ieee80211 stack that's already present in the kernel and drivers that do not have a hardware MAC. Since ieee80211 is already in use in the kernel today, this seemed like a natural and useful extension to the existing code. I agree that it's somewhat wasteful to keep rewriting 802.11 stacks and we considered other options, but it seemed like a more logical choice to work with what was available and recommended than to use an external stack. -Joe - 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
Re: Broadcom 43xx first results
On Mon, 05 Dec 2005 13:46:43 -0500, Jeff Garzik wrote: Use the stack that's already in the kernel. Encouraging otherwise hinders continued wireless progress under Linux. There is nothing like a 802.11 stack currently in the kernel, regardless what James Ketrenos is saying. Sorry. -- Jiri Benc SUSE Labs - 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
Re: Broadcom 43xx first results
Michael Renzmann wrote: Hi. On Mon, 2005-12-05 at 19:00 +0100, Jiri Benc wrote: Why yet another attempt to write 802.11 stack? Sure, the one currently in the kernel is unusable and everybody knows about it. But why not to improve code opensourced by Devicescape some time ago instead of inventing the wheel again and again? Or, in case there is some unknown objection to the mentioned code: use the 802.11 stack that comes along with MadWifi, which provides things like virtual interfaces (for multiple SSID support on one physical card) and WPA support. Although I'm a bit biased towards MadWifi, I'd second your suggestion to make use of the Devicescape code. The benefit of having a fully-blown 802.11 stack in the kernel that drivers can make use of has been discussed before, so I won't go into that yet again. Use the stack that's already in the kernel. Encouraging otherwise hinders continued wireless progress under Linux. Jeff - 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
Re: Broadcom 43xx first results
Jiri Benc wrote: On Mon, 05 Dec 2005 13:46:43 -0500, Jeff Garzik wrote: Use the stack that's already in the kernel. Encouraging otherwise hinders continued wireless progress under Linux. There is nothing like a 802.11 stack currently in the kernel, regardless what James Ketrenos is saying. Sorry. Complete bullshit. There is obviously 802.11 generic code in the kernel, and that's what _I_ am saying, because it's true. If it doesn't support your favorite wireless chipset, then submit patches. Jeff - 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
Re: Broadcom 43xx first results
On Mon, 05 Dec 2005 13:38:37 -0500, Joseph Jezak wrote: We're not writing an entire stack. We're writing a layer that sits in between the current ieee80211 stack that's already present in the kernel and drivers that do not have a hardware MAC. Since ieee80211 is already in use in the kernel today, this seemed like a natural and useful extension to the existing code. I agree that it's somewhat wasteful to keep rewriting 802.11 stacks and we considered other options, but it seemed like a more logical choice to work with what was available and recommended than to use an external stack. Unfortunately, the only long-term solution is to rewrite completely the current in-kernel ieee80211 code (I would not call it a stack) or replace it with something another. The current code was written for Intel devices and it doesn't support anything else - so every developer of a wifi driver tries to implement his own softmac now. I cannot see how this can move as forward and I think we can agree this is not the way to go. Rewriting (or, if you like, enhancing) the current 802.11 code seems to be wasting of time now, when nearly complete Linux stack was opensourced by Devicescape. We can try to merge it, but I'm not convinced it is possible, the Devicescape's stack is far more advanced. -- Jiri Benc SUSE Labs - 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
[PATCH linux-2.6.15-rc5] sk98lin: rx checksum offset not set
The checksum offsets for receive offload were not being set correctly. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] Index: linux-2.6/drivers/net/sk98lin/skge.c === --- linux-2.6.orig/drivers/net/sk98lin/skge.c +++ linux-2.6/drivers/net/sk98lin/skge.c @@ -818,7 +818,7 @@ uintptr_t VNextDescr; /* the virtual bus /* set the pointers right */ pDescr-VNextRxd = VNextDescr 0xULL; pDescr-pNextRxd = pNextDescr; - pDescr-TcpSumStarts = 0; + if (!IsTx) pDescr-TcpSumStarts = ETH_HLEN 16 | ETH_HLEN; /* advance one step */ pPrevDescr = pDescr; @@ -2169,7 +2169,7 @@ rx_start: } /* frame SK_COPY_TRESHOLD */ #ifdef USE_SK_RX_CHECKSUM - pMsg-csum = pRxd-TcpSums; + pMsg-csum = pRxd-TcpSums 0x; pMsg-ip_summed = CHECKSUM_HW; #else pMsg-ip_summed = CHECKSUM_NONE; - 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
Re: Broadcom 43xx first results
On Mon, Dec 05, 2005 at 07:55:43PM +0100, Jiri Benc wrote: Unfortunately, the only long-term solution is to rewrite completely the current in-kernel ieee80211 code (I would not call it a stack) or replace it with something another. The current code was written for Intel devices and it doesn't support anything else - so every developer of a wifi driver tries to implement his own softmac now. I cannot see how this can move as forward and I think we can agree this is not the way to go. Please stop beeing a freaking jackass. There are various projects using the current code. It's not perfect but people are working on it. And Joseph friends are writing a module to support softmac cards in that framework, which is one of the most urgently needed things right now, because all the existing softmac frameworks don't work with that code. And please stop your stupid devicespace advertisements. If you think the code is so useful why don't you send patches to integrate it with the currently existing wireless code (after cleaning up the horrible mess it is currently)? - 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
Re: Broadcom 43xx first results
On Mon, 05 Dec 2005 13:54:00 -0500, Jeff Garzik wrote: Complete bullshit. There is obviously 802.11 generic code in the kernel, and that's what _I_ am saying, because it's true. If it doesn't support your favorite wireless chipset, then submit patches. I have no favorite chipset. I read tons of source code of different drivers instead. Current 802.11 code supports no management stuff at all. And nearly every driver needs support for it - ask any developer of wireless driver except James Ketrenos (oh, wait a moment - although ipw devices do, unlike other devices, a lot of work in firmware, he is implementing in the driver some management stuff too - strange, is not his own stack good enough even for himself?). And, as you might notice, I sent many patches. Only minor ones were accepted. And then I started (and attended) a debate among wireless developers about concepts of 802.11 stack, do you remember? And it gave us interesting results. That results were implemented (patches were sent and not accepted). It may appears that I stopped afterwards, but it is not true. Nearly after that debate had finished, Jouni announced opensourcing of the stack he has been working on for several years. From that time I have been trying to get familiar with that stack, it is quite complex. I have one semi-working driver for it now and I think I know about issues of the stack. -- Jiri Benc SUSE Labs - 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
Re: Broadcom 43xx first results
Jiri Benc wrote: On Mon, 05 Dec 2005 13:38:37 -0500, Joseph Jezak wrote: We're not writing an entire stack. We're writing a layer that sits in between the current ieee80211 stack that's already present in the kernel and drivers that do not have a hardware MAC. Since ieee80211 is already in use in the kernel today, this seemed like a natural and useful extension to the existing code. I agree that it's somewhat wasteful to keep rewriting 802.11 stacks and we considered other options, but it seemed like a more logical choice to work with what was available and recommended than to use an external stack. Unfortunately, the only long-term solution is to rewrite completely the current in-kernel ieee80211 code (I would not call it a stack) or replace it with something another. The current code was written for Intel devices and it doesn't support anything else - so every developer Patently false. ieee80211 is used by Intel. Some bits used by HostAP, which also duplicates a lot of ieee80211 code. And bcm43xx. And another couple drivers found in -mm or out-of-tree. of a wifi driver tries to implement his own softmac now. I cannot see how this can move as forward and I think we can agree this is not the way to go. You're agreeing with only yourself, then? Rewriting (or, if you like, enhancing) the current 802.11 code seems to be wasting of time now, when nearly complete Linux stack was opensourced by Devicescape. We can try to merge it, but I'm not convinced it is possible, the Devicescape's stack is far more advanced. This invalid logic is why we have a ton of wireless stacks, all duplicating each other. Jeff - 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
Re: Broadcom 43xx first results
On Mon, 05 Dec 2005 14:08:28 -0500, Jeff Garzik wrote: Patently false. ieee80211 is used by Intel. Some bits used by HostAP, which also duplicates a lot of ieee80211 code. And bcm43xx. And another couple drivers found in -mm or out-of-tree. Hostap uses only encryption code, which was copied from - guess who - hostap. Everything other must be done by the hostap driver itself. bcm43xx can use - like every other driver - only constants and defines from ieee80211.h. This is the reason why they are trying to implement softmac on top of it. But that work was already done by Jouni. of a wifi driver tries to implement his own softmac now. I cannot see how this can move as forward and I think we can agree this is not the way to go. You're agreeing with only yourself, then? I meant that every driver tries to implements its own softmac. This is not the way to go, right? Rewriting (or, if you like, enhancing) the current 802.11 code seems to be wasting of time now, when nearly complete Linux stack was opensourced by Devicescape. We can try to merge it, but I'm not convinced it is possible, the Devicescape's stack is far more advanced. This invalid logic is why we have a ton of wireless stacks, all duplicating each other. Heh? We have one nearly finished stack (and no, it's not the one in kernel). Why should we try to implement a new stack instead of fixing some issues of the nearly finished one? -- Jiri Benc SUSE Labs - 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
Re: [PATCH linux-2.6.15-rc5] sk98lin: rx checksum offset not set
On Mon, Dec 05, 2005, Stephen Hemminger wrote: The checksum offsets for receive offload were not being set correctly. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] I can confirm that this patch fixes the problem for me. Thanks, Johannes Index: linux-2.6/drivers/net/sk98lin/skge.c === --- linux-2.6.orig/drivers/net/sk98lin/skge.c +++ linux-2.6/drivers/net/sk98lin/skge.c @@ -818,7 +818,7 @@ uintptr_t VNextDescr; /* the virtual bus /* set the pointers right */ pDescr-VNextRxd = VNextDescr 0xULL; pDescr-pNextRxd = pNextDescr; - pDescr-TcpSumStarts = 0; + if (!IsTx) pDescr-TcpSumStarts = ETH_HLEN 16 | ETH_HLEN; /* advance one step */ pPrevDescr = pDescr; @@ -2169,7 +2169,7 @@ rx_start: } /* frame SK_COPY_TRESHOLD */ #ifdef USE_SK_RX_CHECKSUM - pMsg-csum = pRxd-TcpSums; + pMsg-csum = pRxd-TcpSums 0x; pMsg-ip_summed = CHECKSUM_HW; #else pMsg-ip_summed = CHECKSUM_NONE; - 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
Re: Broadcom 43xx first results
On Mon, 5 Dec 2005 19:10:08 +, Christoph Hellwig wrote: Please stop beeing a freaking jackass. There are various projects using the current code. It's not perfect but people are working on it. Yes, and everyone implements his own softmac (this is the third one I know about). I tried to put all of these efforts together (google through the netdev archives) and wrote many patches. And Joseph friends are writing a module to support softmac cards in that framework, which is one of the most urgently needed things right now, because all the existing softmac frameworks don't work with that code. And authors of rtl8180 did it too. And authors of adm8211 too. And please stop your stupid devicespace advertisements. If you think the code is so useful why don't you send patches to integrate it with the currently existing wireless code (after cleaning up the horrible mess it is currently)? This is what I'm doing last two months. But it's not so easy to clean it up and it seems that nobody else is interested. But it has all of the features you need (except active scanning) - this is the reason I stopped to work on improving current in-kernel 802.11 code and focused on Devicescape's code. It is several years beyond the state that current code is at now. And it is not an advertisement, it is a fact. -- Jiri Benc SUSE Labs - 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
Re: Broadcom 43xx first results
On Mon, Dec 05, 2005 at 08:31:21PM +0100, Jiri Benc wrote: And Joseph friends are writing a module to support softmac cards in that framework, which is one of the most urgently needed things right now, because all the existing softmac frameworks don't work with that code. And authors of rtl8180 did it too. And authors of adm8211 too. None of them made it into the kernel tree. As soon as we'll have an acceptable one everyone will have to use and improve it. I personally couldn't care less what we start with. And please stop your stupid devicespace advertisements. If you think the code is so useful why don't you send patches to integrate it with the currently existing wireless code (after cleaning up the horrible mess it is currently)? This is what I'm doing last two months. But it's not so easy to clean it up and it seems that nobody else is interested. But it has all of the features you need (except active scanning) - this is the reason I stopped to work on improving current in-kernel 802.11 code and focused on Devicescape's code. It is several years beyond the state that current code is at now. And it is not an advertisement, it is a fact. That's because you still don't get how we do development. The last thing we want is full-scale rewrites. Submit patches to fix things based on whatever you want but do it incremental. Anything that just moves existing functionaly out of the place and adds duplicates with more functionality/ cleaner API/buzzword of the day is simply not acceptable. - 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
Re: Broadcom 43xx first results
On Mon, Dec 05, 2005 at 02:08:28PM -0500, Jeff Garzik wrote: Jiri Benc wrote: On Mon, 05 Dec 2005 13:38:37 -0500, Joseph Jezak wrote: We're not writing an entire stack. We're writing a layer that sits in between the current ieee80211 stack that's already present in the kernel and drivers that do not have a hardware MAC. Since ieee80211 is already in use in the kernel today, this seemed like a natural and useful extension to the existing code. I agree that it's somewhat wasteful to keep rewriting 802.11 stacks and we considered other options, but it seemed like a more logical choice to work with what was available and recommended than to use an external stack. Unfortunately, the only long-term solution is to rewrite completely the current in-kernel ieee80211 code (I would not call it a stack) or replace it with something another. The current code was written for Intel devices and it doesn't support anything else - so every developer Patently false. ieee80211 is used by Intel. Some bits used by HostAP, which also duplicates a lot of ieee80211 code. And bcm43xx. And another couple drivers found in -mm or out-of-tree. Orinoco also uses it now no ? Dave - 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
Re: Broadcom 43xx first results
On Mon, 5 Dec 2005 19:41:46 +, Christoph Hellwig wrote: None of them made it into the kernel tree. As soon as we'll have an acceptable one everyone will have to use and improve it. I personally couldn't care less what we start with. Same with me. That's because you still don't get how we do development. The last thing we want is full-scale rewrites. Submit patches to fix things based on whatever you want but do it incremental. We have got almost finished and working stack. Everything we need to do is: 1. identify issues; 2. fix the issues; some of them will need broader discussion; 3. split it into several (potentially a lot of) reviewable patches; 4. clean up the drivers. I'm in phase 2 now (no interesting results yet). I don't think it is possible to start by phase 3 and then skip back to 1 and 2... This is the reason I didn't post anything yet (or did you see some bloated everything-rewriting patch from me posted on the list?). But I also don't think it is worth effort to reinvent wheel by writing all of the stuff again. This is the reason I started to examine Devicescape code, nothing more. And if you are familiar with the current in-kernel 802.11 code (and if you know at least two different drivers), you will probably agree that many things have to be changed in the current code even if we decided to build on the top of it, so the result will finally differ a lot and will be almost incompatible with the current code. (Why? I think I wrote some explanation already to netdev list - if you don't find it or it is not understandable, please let me know, I will try again.) -- Jiri Benc SUSE Labs - 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
Re: Broadcom 43xx first results
Dave Jones wrote: On Mon, Dec 05, 2005 at 02:08:28PM -0500, Jeff Garzik wrote: Jiri Benc wrote: On Mon, 05 Dec 2005 13:38:37 -0500, Joseph Jezak wrote: We're not writing an entire stack. We're writing a layer that sits in between the current ieee80211 stack that's already present in the kernel and drivers that do not have a hardware MAC. Since ieee80211 is already in use in the kernel today, this seemed like a natural and useful extension to the existing code. I agree that it's somewhat wasteful to keep rewriting 802.11 stacks and we considered other options, but it seemed like a more logical choice to work with what was available and recommended than to use an external stack. Unfortunately, the only long-term solution is to rewrite completely the current in-kernel ieee80211 code (I would not call it a stack) or replace it with something another. The current code was written for Intel devices and it doesn't support anything else - so every developer Patently false. ieee80211 is used by Intel. Some bits used by HostAP, which also duplicates a lot of ieee80211 code. And bcm43xx. And another couple drivers found in -mm or out-of-tree. Orinoco also uses it now no ? Just the headers, really. Jeff - 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
Re: Broadcom 43xx first results
On Monday 05 December 2005 19:00, you wrote: On Sun, 04 Dec 2005 19:50:08 +0100, [EMAIL PROTECTED] wrote: The team is in the progress of writing a SoftwareMAC layer, which is needed for the bcm device. The SoftMAC is still very incomplete. So do not expect to do any fancy stuff like WPA or something line that with it. Why yet another attempt to write 802.11 stack? Sure, the one currently in the kernel is unusable and everybody knows about it. But why not to improve code opensourced by Devicescape some time ago instead of inventing the wheel again and again? Yes, I know that code is not perfect and needs a lot of work, but it is the best piece of code we have available now. And it _does_ support WPA and such - in fact, it is nearly complete. This is __not__ yet another stack. It is an _extension_. It is all about management frames, which the in-kernel code does not manage. We want a working device. The driver is in a state where it is more or less usable. What is missing, is code to handle management. We tried the code from the RTL driver, but it is total crap. We dropped it again. We thought about using yet another out of kernel ieee80211 stack, but we began to write an extension to the in-kernel code. If that was right or wrong, well, that's the question. If you _really_ think we should have used $EXTERNAL_STACK, go and patch the driver to work with it. I would really like to see it working. It is easy to change the used 80211 stack, as it is only a task of replacing TX and RX function calls (and a few parameter settings to the ieee struct on init). PS: I forgot to mention in the announcement, that the driver has problems with OFDM (that are all 802.11g) rates. So use 802.11b rates. 11MBit works fine. -- Greetings Michael. pgplReQyyxnWk.pgp Description: PGP signature
Re: Broadcom 43xx first results
On Mon, 5 Dec 2005 21:23:42 +0100, Michael Buesch wrote: This is __not__ yet another stack. It is an _extension_. It is all about management frames, which the in-kernel code does not manage. But this code should be part of the stack, as nearly every driver needs it. Management handling should be really managed by the kernel. The same applies to driver-userspace communication - there is no need to bother every driver with it. And so on. The hard part is that every driver will need a slightly different amount of this support depending on the amount of features that are provided by firmware. We want a working device. The driver is in a state where it is more or less usable. What is missing, is code to handle management. I understand. We tried the code from the RTL driver, but it is total crap. We dropped it again. We thought about using yet another out of kernel ieee80211 stack, but we began to write an extension to the in-kernel code. If that was right or wrong, well, that's the question. If you _really_ think we should have used $EXTERNAL_STACK, go and patch the driver to work with it. No. I just think we (everybody) should concentrate at one particular stack, finish it and merge it. And I'm convinced Jouni's stack is currently the best solution available - far far from perfect, with many issues, but still the best - and it will finally save as much time. -- Jiri Benc SUSE Labs - 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
Re: [RFC] ip / ifconfig redesign
On Mon, Dec 05, 2005 at 06:59:07PM +0100, Jeroen Massar wrote: Marc Singer wrote: On Mon, Dec 05, 2005 at 09:01:00AM -0500, John W. Linville wrote: On Sat, Dec 03, 2005 at 10:33:32AM -0800, Ben Greear wrote: SNIP The association between IP addresses and links is already a bit murky. Reference the arp_announce sysctl for what I mean. I recall Dave M. emphasizing on at least one occassion that IP addresses belong to the _box_, not to the link. Precisely the case. It should be the case that a box response to an arp on *any* interface for *any* IP address known to the box. Thus you have the following nice setup: 10.100.10.0/24 = 10Gbit streaming network 10.100.20.0/24 = 10mbit admin network 10.100.10.1 on eth0 10.100.20.1 on eth2 Then some idiot misconfigures his client box, putting 10.100.10.42/24 on the NIC that is supposed to be in the admin network only. Suddenly your 10mbit link is full because the arp's get answered on this link. Huh? The arp requests don't establish routing and they aren't a significant source of traffic. Besides, all I suggested is that if a machine receives an arp request on eth2 for an address it has on 10.100.10/24, it should answer with it's MAC address on eth2. My readings of the RFC do not address this issue directly. My understand of this behaviour is from a discussion with someone regarding iptables. Moreover, if you allow users to willy-nilly connect to your networks, you've got a completely different kind of problem on your hands. - 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
Re: [RFC] ip / ifconfig redesign
John W. Linville wrote: Al Boldi wrote: Here specifically, ip/ifconfig is implemented upside-down requiring a link/dev to exist for an address to be defined, in effect containing layer 3 inside layer 2, when an address should be allowed to be defined w/o a link/dev much like an app is allowed to be defined w/o an address. I think Al B.'s idea merits some consideration. I definitely think we blur the distinctions between L2 and L3 a bit too much in places. Of course, patches would be helpful... I am envisaging a complete decoupling of the current implementation to achieve OSI compliance. And that's not for the sake of OSI but for the sake of scalability. This means that it should be possible define a layer 3 network architecture completely independent of a layer 2 link architecture. This also means that we are free to choose means other than a layer 2 link to fulfill layer 3 requests and vice/versa. And it may open the door to many other things... due to scalability. Thanks! -- Al - 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
Re: [RFC] ip / ifconfig redesign
On Mon, Dec 05, 2005 at 10:00:41AM -0800, Ben Greear wrote: Precisely the case. It should be the case that a box response to an arp on *any* interface for *any* IP address known to the box. I certainly don't mind if this is a configurable, or even default behaviour, but we also need the ability to only respond to particular arps on particular interfaces, based on the IP addresses assigned to those interfaces. Why? The routing determines connectivity, not ARP. AFAIK, ARP requests are not made on interfaces that lack that the network being queried. If I put a host with an address on network 12 onto an ethernet segment for network 10 and then ARP for addresses on network 10, I ought to be able to send packets to those hosts (baring a firewal). However, I won't be able to get anything back because those hosts don't know how to send to network 12. Misconfiguration? Yes. Non-compliant? No. I am able to get this particular arp binding working today, so I'm not suggesting changes, just mentioning that there are other configurations than what you mention that are useful to people. Anyway, I haven't seen a good reason to change the current behavior. While the above described functionality is missing, no one has made a case to support it. - 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
Re: [2.6 patch] move some code to net/ipx/af_ipx.c
On Fri, Nov 18, 2005 at 06:24:10PM -0200, Arnaldo Carvalho de Melo wrote: On 11/18/05, Adrian Bunk [EMAIL PROTECTED] wrote: On Mon, Nov 14, 2005 at 02:57:07AM +0100, Adrian Bunk wrote: On Fri, Nov 11, 2005 at 02:35:51AM -0600, Matt Mackall wrote: trivial: drop unused 802.3 code if we compile without IPX (originally from http://wohnheim.fh-wedel.de/~joern/software/kernel/je/25/) Thanks Adrian, from a quick glance looks OK, I'll review it later today to see if everything is fine wrt appletalk, tr, etc. Any result from your review? - Arnaldo cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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
[PATCH 11/14] spidernet: fix Kconfig after BPA-CELL rename
We changed the name of the Kconfig symbols along with the move to arch/powerpc. This one hunk got lost during the conversion. From: [EMAIL PROTECTED] Cc: netdev@vger.kernel.org Signed-off-by: Arnd Bergmann [EMAIL PROTECTED] Index: linux-2.6.15-rc1/drivers/net/Kconfig === --- linux-2.6.15-rc1.orig/drivers/net/Kconfig +++ linux-2.6.15-rc1/drivers/net/Kconfig @@ -2120,7 +2120,7 @@ config BNX2 config SPIDER_NET tristate Spider Gigabit Ethernet driver - depends on PCI PPC_BPA + depends on PCI PPC_CELL help This driver supports the Gigabit Ethernet chips present on the Cell Processor-Based Blades from IBM. -- - 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
[PATCH 12/14] spidernet: check if firmware was loaded correctly
Uploading the device firmware may fail if wrong input data
was provided by the user. This checks for the condition.
From: [EMAIL PROTECTED]
Cc: netdev@vger.kernel.org
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
Index: linux-2.6.15-rc/drivers/net/spider_net.c
===
--- linux-2.6.15-rc.orig/drivers/net/spider_net.c
+++ linux-2.6.15-rc/drivers/net/spider_net.c
@@ -1836,7 +1836,7 @@ spider_net_setup_phy(struct spider_net_c
* spider_net_download_firmware loads the firmware opened by
* spider_net_init_firmware into the adapter.
*/
-static void
+static int
spider_net_download_firmware(struct spider_net_card *card,
const struct firmware *firmware)
{
@@ -1857,8 +1857,13 @@ spider_net_download_firmware(struct spid
}
}
+ if (spider_net_read_reg(card, SPIDER_NET_GSINIT))
+ return -EIO;
+
spider_net_write_reg(card, SPIDER_NET_GSINIT,
SPIDER_NET_RUN_SEQ_VALUE);
+
+ return 0;
}
/**
@@ -1909,9 +1914,8 @@ spider_net_init_firmware(struct spider_n
goto out;
}
- spider_net_download_firmware(card, firmware);
-
- err = 0;
+ if (!spider_net_download_firmware(card, firmware))
+ err = 0;
out:
release_firmware(firmware);
Index: linux-2.6.15-rc/drivers/net/spider_net.h
===
--- linux-2.6.15-rc.orig/drivers/net/spider_net.h
+++ linux-2.6.15-rc/drivers/net/spider_net.h
@@ -155,7 +155,7 @@ extern char spider_net_driver_name[];
/* set this first, then the FRAMENUM_VALUE */
#define SPIDER_NET_GFXFRAMES_VALUE 0x
-#define SPIDER_NET_STOP_SEQ_VALUE 0x
+#define SPIDER_NET_STOP_SEQ_VALUE 0x007e
#define SPIDER_NET_RUN_SEQ_VALUE 0x007e
#define SPIDER_NET_PHY_CTRL_VALUE 0x00040040
--
-
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
[PATCH 13/14] spidernet: read firmware from the OF device tree
request_firmware() is sometimes problematic, especially
in initramfs, reading the firmware from Open Firmware
is much preferrable.
We still try to get the firmware from the file system
first, in order to support old SLOF releases and to allow
updates of the spidernet firmware without reflashing
the system.
From: [EMAIL PROTECTED]
Cc: netdev@vger.kernel.org
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
Index: linux-2.6.15-rc/drivers/net/spider_net.c
===
--- linux-2.6.15-rc.orig/drivers/net/spider_net.c
+++ linux-2.6.15-rc/drivers/net/spider_net.c
@@ -1895,16 +1895,27 @@ spider_net_download_firmware(struct spid
static int
spider_net_init_firmware(struct spider_net_card *card)
{
- const struct firmware *firmware;
+ struct firmware *firmware;
+ struct device_node *dn;
+ u8 *fw_prop;
int err = -EIO;
- if (request_firmware(firmware,
+ if (request_firmware((const struct firmware **)firmware,
SPIDER_NET_FIRMWARE_NAME, card-pdev-dev) 0) {
if (netif_msg_probe(card))
pr_err(Couldn't read in sequencer data file %s.\n,
SPIDER_NET_FIRMWARE_NAME);
- firmware = NULL;
- goto out;
+
+ dn = pci_device_to_OF_node(card-pdev);
+ if (!dn)
+ goto out;
+
+ fw_prop = (u8 *)get_property(dn, firmware, NULL);
+ if (!fw_prop)
+ goto out;
+
+ memcpy(firmware-data, fw_prop, 6 * SPIDER_NET_FIRMWARE_LEN *
sizeof(u32));
+ firmware-size = 6 * SPIDER_NET_FIRMWARE_LEN * sizeof(u32);
}
if (firmware-size != 6 * SPIDER_NET_FIRMWARE_LEN * sizeof(u32)) {
--
-
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
[PATCH 14/14] spidernet: fix HW structures for 64 bit dma_addr_t
The driver incorrectly used dma_addr_t to describe
HW structures and consequently broke when that type
was changed in 2.6.15-rc.
This changed spidernet to use u32 for 32 bit HW defined
structure elements.
From: [EMAIL PROTECTED]
Cc: netdev@vger.kernel.org
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
Index: linux-2.6.15-rc/drivers/net/spider_net.h
===
--- linux-2.6.15-rc.orig/drivers/net/spider_net.h
+++ linux-2.6.15-rc/drivers/net/spider_net.h
@@ -373,9 +373,9 @@ enum spider_net_descr_status {
struct spider_net_descr {
/* as defined by the hardware */
- dma_addr_t buf_addr;
+ u32 buf_addr;
u32 buf_size;
- dma_addr_t next_descr_addr;
+ u32 next_descr_addr;
u32 dmac_cmd_status;
u32 result_size;
u32 valid_size; /* all zeroes for tx */
Index: linux-2.6.15-rc/drivers/net/spider_net.c
===
--- linux-2.6.15-rc.orig/drivers/net/spider_net.c
+++ linux-2.6.15-rc/drivers/net/spider_net.c
@@ -480,6 +480,7 @@ static int
spider_net_prepare_rx_descr(struct spider_net_card *card,
struct spider_net_descr *descr)
{
+ dma_addr_t buf;
int error = 0;
int offset;
int bufsize;
@@ -510,10 +511,11 @@ spider_net_prepare_rx_descr(struct spide
if (offset)
skb_reserve(descr-skb, SPIDER_NET_RXBUF_ALIGN - offset);
/* io-mmu-map the skb */
- descr-buf_addr = pci_map_single(card-pdev, descr-skb-data,
+ buf = pci_map_single(card-pdev, descr-skb-data,
SPIDER_NET_MAX_MTU,
PCI_DMA_BIDIRECTIONAL);
- if (descr-buf_addr == DMA_ERROR_CODE) {
+ descr-buf_addr = buf;
+ if (buf == DMA_ERROR_CODE) {
dev_kfree_skb_any(descr-skb);
if (netif_msg_rx_err(card))
pr_err(Could not iommu-map rx buffer\n);
@@ -914,15 +916,16 @@ spider_net_prepare_tx_descr(struct spide
struct spider_net_descr *descr,
struct sk_buff *skb)
{
- descr-buf_addr = pci_map_single(card-pdev, skb-data,
-skb-len, PCI_DMA_BIDIRECTIONAL);
- if (descr-buf_addr == DMA_ERROR_CODE) {
+ dma_addr_t buf = pci_map_single(card-pdev, skb-data,
+ skb-len, PCI_DMA_BIDIRECTIONAL);
+ if (buf == DMA_ERROR_CODE) {
if (netif_msg_tx_err(card))
pr_err(could not iommu-map packet (%p, %i).
Dropping packet\n, skb-data, skb-len);
return -ENOMEM;
}
+ descr-buf_addr = buf;
descr-buf_size = skb-len;
descr-skb = skb;
descr-data_status = 0;
--
-
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
Re: [RFC] ip / ifconfig redesign
John Heffner wrote: Rick Jones wrote: That's the discussion related to things like the Strong ES (end system) model right? As such, isn't that discussing what _IP_ may do rather than what ARP may do? 1122 doesn't say much about the interfaces/MAC's that should be part of a given ARP reply. ARP seems to be RFC 826 and probably others, and the algorithm described in 826 doesn't seem to be specific on the topic of interfaces - at least not to my really brief read. rick jones Yes, but if an interface will accept packets for a certain IP address, and will send packets with that IP address, is there any reason it can't ARP for that address? If ARP RFC's say it shouldn't :) (I don't know that it does) ARP is ARP, accepting IPs is IP. The maze of twisty passages may be similar, but they are distinct. Is a MAC address a property of the host, or of the interface connected to the host? rick jones is on netdev, so no need for direct reply to my address... - 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
Re: [RFC] ip / ifconfig redesign
John Heffner wrote: Jeroen Massar wrote: I wonder how many RFC's it violates. An interface must only answer ARP's on the interface that it is configured on, not anything else. Not true. See RFC 1122, section 3.3.4. The standard leaves this decision up to the implementation, for good reason. RFC1122 is a document about multicast. ARP is broadcast see the very old RFC826/STD0037. Multicast didn't even work on much of the hardware from the times that that document was written. Probably the best text about this subject can be found in RFC1027: 8--- 2.4 Sanity checks Care must be taken by the network and gateway administrators to keep the network masks the same on all the subnet gateway machines. The most common error is to set the network mask on a host without a subnet implementation to include the subnet number. This causes the host to fail to attempt to send packets to hosts not on its local subnet. Adjusting its routing tables will not help, since it will not know how to route to subnets. If the IP networks of the source and target hosts of an ARP request are different, an ARP subnet gateway implementation should not reply. This is to prevent the ARP subnet gateway from being used to reach foreign IP networks and thus possibly bypass security checks provided by IP gateways. --8 Which is almost the same as what I noted. Note that the document is about Proxy ARP, when a host is responding ARP queries for an IP on a different link, this is exactly what it is doing: proxy arp. This topic has been discussed many times on a variety of mailing lists. I think the best way to do this is to make the behavior configurable, which Linux currently does. As long as the default is off I am fine with it, people turning it on themselves break their own network :) Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: [RFC] ip / ifconfig redesign
Rick Jones wrote: John Heffner wrote: Yes, but if an interface will accept packets for a certain IP address, and will send packets with that IP address, is there any reason it can't ARP for that address? If ARP RFC's say it shouldn't :) (I don't know that it does) ARP is ARP, accepting IPs is IP. The maze of twisty passages may be similar, but they are distinct. I actually think it would be out of scope for an ARP RFC to specify this (and none I'm aware of do). It really is an IP layer decision. That is, the decision naturally extends beyond the scope of ARP, applying also to layer 2 devices which don't even do ARP. Is a MAC address a property of the host, or of the interface connected to the host? Depends on whether you run your interfaces in promiscuous mode, and send frames with different MAC addresses from one interface. ;-) -John - 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
Re: [RFC] ip / ifconfig redesign
John Heffner wrote: Jeroen Massar wrote: John Heffner wrote: Jeroen Massar wrote: I wonder how many RFC's it violates. An interface must only answer ARP's on the interface that it is configured on, not anything else. Not true. See RFC 1122, section 3.3.4. The standard leaves this decision up to the implementation, for good reason. RFC1122 is a document about multicast. ARP is broadcast see the very old RFC826/STD0037. Multicast didn't even work on much of the hardware from the times that that document was written. ??? RFC 1122 is the Hosts Requirements RFC. It applies to any host implementing IP. Maybe you're thinking of 1112? Oops, mixed up a number. 1122 refers to 826, with 1027 extending it partially for situations where one is multihomed. Section 3.3.4 of 1122 is about IP and not about ARP, which is, just like IP directly on top of Ethernet. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: [PATCH] natsemi: NAPI support
On Mon, Dec 05, 2005 at 12:12:09AM +0100, Francois Romieu wrote: - netif_poll_disable() may sleep while a spinlock is held. So it can, thanks. Btw, the poll/close routines seem racy with each other. I had been under the impression that the stack was supposed to make sure that no poll() is running before the driver close() gets called? I could well be missing something there, though. Indeed, now that I think about it the calls netif_poll_disable() in suspend() ought to mean that we don't need to look at hands_off inside poll(). -- You grabbed my hand and we fell into it, like a daydream - or a fever. signature.asc Description: Digital signature
Re: [2.6 patch] net/: fix the WIRELESS_EXT abuse
Adrian Bunk wrote : Using WIRELESS_EXT instead of CONFIG_NET_RADIO is simply ugly. Sorry, but I did not see this e-mail in my inbox. Maybe my spam filter is too agressive. I would prefer that to the alternative... You are probably right that something need to be done about it, but I believe this is the wrong direction. I would prefer you to replace WIRELESS_EXT with CONFIG_WIRELESS_EXT. Historically, CONFIG_NET_RADIO has always been the option to enable WLAN drivers. The same way CONFIG_NETDEVICES enable all network drivers. A long time ago, I did abuse CONFIG_NET_RADIO to also enable Wireless Extensions. Not being totally happy about it, I try to minimise to use of CONFIG_NET_RADIO in the *generic* network code so that we could revert that easily. Now is probably the time. Kernel 2.6.14 introduce a generic 802.11 stack in the kernel. This stack depends on Wireless Extensions. Now we have the messy situation of having a generic network component that depend on a driver option and enables it. I propose that Wireless Extension have it's own separate CONFIG_WIRELESS_EXT. Both CONFIG_NET_RADIO and CONFIG_IEEE80211 would depend on it and enables it. What do you think of that ? Jean - 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
Re: [PATCH] natsemi: NAPI support
Mark Brown [EMAIL PROTECTED] : [...] I had been under the impression that the stack was supposed to make sure that no poll() is running before the driver close() gets called ? Not exactly. dev_close() waits a bit but it can not be sure that the device driver will not schedule -poll() from its irq handler later. -- Ueimor - 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
Lockless TX and netif_wake/stop
I assert that with lockless transmit (ie NETIF_F_LLTX) it is possible for two cpu's to race with the transmit flow control (netif_stop_queue/netif_wake_queue). I see it with sky2, and probably could reproduce with tg3 as well. A. CPU is in middle of building up a transmit, B. CPU gets packet and passes netif_queue_stopped test A. CPU completes transmit and since tx queue is full sets stopped B. tests for tx queue full and This will cause the driver to return DEVICE_BUSY Tg3, skge, sky2 and rionet all print message, that this is a BUG! but it is just losing a corner case race, and should be silent. -- Stephen Hemminger [EMAIL PROTECTED] OSDL http://developer.osdl.org/~shemminger - 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
Re: Lockless TX and netif_wake/stop
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Mon, 5 Dec 2005 16:37:53 -0800
I assert that with lockless transmit (ie NETIF_F_LLTX) it is
possible for two cpu's to race with the transmit flow control
(netif_stop_queue/netif_wake_queue). I see it with sky2, and
probably could reproduce with tg3 as well.
A. CPU is in middle of building up a transmit,
B. CPU gets packet and passes
netif_queue_stopped test
A. CPU completes transmit and since tx queue is full sets stopped
B. tests for tx queue full and
This will cause the driver to return DEVICE_BUSY
Tg3, skge, sky2 and rionet all print message, that this is a BUG!
but it is just losing a corner case race, and should be silent.
I totally agree, but would recommend something like the patch below,
using tg3 as an example.
We should still warn if the transmit ring is full _and_ netif_stop_queue()
is false. That is an illegal state to observe while holding the tx_lock.
If netif_stop_queue() is true, then it's just the race you describe above,
and should just silently return NETDEV_TX_BUSY, as you recommend.
Agreed?
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 1828a6b..d9f65f4 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -3565,12 +3565,20 @@ static int tg3_start_xmit(struct sk_buff
if (!spin_trylock(tp-tx_lock))
return NETDEV_TX_LOCKED;
- /* This is a hard error, log it. */
if (unlikely(TX_BUFFS_AVAIL(tp) = (skb_shinfo(skb)-nr_frags + 1))) {
- netif_stop_queue(dev);
+ int was_stopped = netif_queue_stopped(dev);
+
+ if (!was_stopped)
+ netif_stop_queue(dev);
+
spin_unlock(tp-tx_lock);
- printk(KERN_ERR PFX %s: BUG! Tx Ring full when queue awake!\n,
- dev-name);
+
+ if (!was_stopped) {
+ /* This is a hard error, log it. */
+ printk(KERN_ERR PFX %s: BUG! Tx Ring full when
+ queue awake!\n, dev-name);
+ }
+
return NETDEV_TX_BUSY;
}
-
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
[IPVS] remove dead code
ip_vs_app.c | 28
ip_vs_lblc.c | 27 ---
ip_vs_lblcr.c | 27 ---
ip_vs_proto_tcp.c | 22 --
4 files changed, 104 deletions(-)
Please apply
--
Horms
[IPVS] remove dead code
This patch removes dead code. I don't see the reason to keep this cruft
around, besides cluttering the nice and functionally working code.
Trivial, please apply.
Signed-off-by: Roberto Nibali [EMAIL PROTECTED]
Signed-off-by: Horms [EMAIL PROTECTED]
diff --git a/net/ipv4/ipvs/ip_vs_app.c b/net/ipv4/ipvs/ip_vs_app.c
index d7eb680..9b176a9 100644
--- a/net/ipv4/ipvs/ip_vs_app.c
+++ b/net/ipv4/ipvs/ip_vs_app.c
@@ -224,34 +224,6 @@ void unregister_ip_vs_app(struct ip_vs_a
}
-#if
-/*
- * Get reference to app by name (called from user context)
- */
-struct ip_vs_app *ip_vs_app_get_by_name(char *appname)
-{
- struct ip_vs_app *app, *a = NULL;
-
- down(__ip_vs_app_mutex);
-
- list_for_each_entry(ent, ip_vs_app_list, a_list) {
- if (strcmp(app-name, appname))
- continue;
-
- /* softirq may call ip_vs_app_get too, so the caller
- must disable softirq on the current CPU */
- if (ip_vs_app_get(app))
- a = app;
- break;
- }
-
- up(__ip_vs_app_mutex);
-
- return a;
-}
-#endif
-
-
/*
* Bind ip_vs_conn to its ip_vs_app (called by cp constructor)
*/
diff --git a/net/ipv4/ipvs/ip_vs_lblc.c b/net/ipv4/ipvs/ip_vs_lblc.c
index 561cda3..b6dad7e 100644
--- a/net/ipv4/ipvs/ip_vs_lblc.c
+++ b/net/ipv4/ipvs/ip_vs_lblc.c
@@ -228,33 +228,6 @@ ip_vs_lblc_hash(struct ip_vs_lblc_table
}
-#if
-/*
- * Unhash ip_vs_lblc_entry from ip_vs_lblc_table.
- * returns bool success.
- */
-static int ip_vs_lblc_unhash(struct ip_vs_lblc_table *tbl,
-struct ip_vs_lblc_entry *en)
-{
- if (list_empty(en-list)) {
- IP_VS_ERR(ip_vs_lblc_unhash(): request for not hashed entry,
- called from %p\n, __builtin_return_address(0));
- return 0;
- }
-
- /*
-* Remove it from the table
-*/
- write_lock(tbl-lock);
- list_del(en-list);
- INIT_LIST_HEAD(en-list);
- write_unlock(tbl-lock);
-
- return 1;
-}
-#endif
-
-
/*
* Get ip_vs_lblc_entry associated with supplied parameters.
*/
diff --git a/net/ipv4/ipvs/ip_vs_lblcr.c b/net/ipv4/ipvs/ip_vs_lblcr.c
index ce456db..8c78ef7 100644
--- a/net/ipv4/ipvs/ip_vs_lblcr.c
+++ b/net/ipv4/ipvs/ip_vs_lblcr.c
@@ -414,33 +414,6 @@ ip_vs_lblcr_hash(struct ip_vs_lblcr_tabl
}
-#if
-/*
- * Unhash ip_vs_lblcr_entry from ip_vs_lblcr_table.
- * returns bool success.
- */
-static int ip_vs_lblcr_unhash(struct ip_vs_lblcr_table *tbl,
-struct ip_vs_lblcr_entry *en)
-{
- if (list_empty(en-list)) {
- IP_VS_ERR(ip_vs_lblcr_unhash(): request for not hashed entry,
- called from %p\n, __builtin_return_address(0));
- return 0;
- }
-
- /*
-* Remove it from the table
-*/
- write_lock(tbl-lock);
- list_del(en-list);
- INIT_LIST_HEAD(en-list);
- write_unlock(tbl-lock);
-
- return 1;
-}
-#endif
-
-
/*
* Get ip_vs_lblcr_entry associated with supplied parameters.
*/
diff --git a/net/ipv4/ipvs/ip_vs_proto_tcp.c b/net/ipv4/ipvs/ip_vs_proto_tcp.c
index 0e878fd..638ba8c 100644
--- a/net/ipv4/ipvs/ip_vs_proto_tcp.c
+++ b/net/ipv4/ipvs/ip_vs_proto_tcp.c
@@ -275,28 +275,6 @@ static int tcp_timeouts[IP_VS_TCP_S_LAST
[IP_VS_TCP_S_LAST] = 2*HZ,
};
-
-#if 0
-
-/* FIXME: This is going to die */
-
-static int tcp_timeouts_dos[IP_VS_TCP_S_LAST+1] = {
- [IP_VS_TCP_S_NONE] = 2*HZ,
- [IP_VS_TCP_S_ESTABLISHED] = 8*60*HZ,
- [IP_VS_TCP_S_SYN_SENT] = 60*HZ,
- [IP_VS_TCP_S_SYN_RECV] = 10*HZ,
- [IP_VS_TCP_S_FIN_WAIT] = 60*HZ,
- [IP_VS_TCP_S_TIME_WAIT] = 60*HZ,
- [IP_VS_TCP_S_CLOSE] = 10*HZ,
- [IP_VS_TCP_S_CLOSE_WAIT]= 60*HZ,
- [IP_VS_TCP_S_LAST_ACK] = 30*HZ,
- [IP_VS_TCP_S_LISTEN]= 2*60*HZ,
- [IP_VS_TCP_S_SYNACK]= 100*HZ,
- [IP_VS_TCP_S_LAST] = 2*HZ,
-};
-
-#endif
-
static char * tcp_state_name_table[IP_VS_TCP_S_LAST+1] = {
[IP_VS_TCP_S_NONE] = NONE,
[IP_VS_TCP_S_ESTABLISHED] = ESTABLISHED,
-
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
Re: [2.6 patch] net/: fix the WIRELESS_EXT abuse
On Mon, Dec 05, 2005 at 03:51:36PM -0800, jt wrote: Adrian Bunk wrote : Using WIRELESS_EXT instead of CONFIG_NET_RADIO is simply ugly. You are probably right that something need to be done about it, but I believe this is the wrong direction. I would prefer you to replace WIRELESS_EXT with CONFIG_WIRELESS_EXT. [...] Less talk, more patches. What do you guys think of the attached patch. Please try it... Jean -- diff -u -p linux/drivers/net/wireless/Kconfig-j1 linux/drivers/net/wireless/Kconfig --- linux/drivers/net/wireless/Kconfig-j1 2005-12-05 18:14:11.0 -0800 +++ linux/drivers/net/wireless/Kconfig 2005-12-05 18:35:09.0 -0800 @@ -6,24 +6,12 @@ menu Wireless LAN (non-hamradio) depends on NETDEVICES config NET_RADIO - bool Wireless LAN drivers (non-hamradio) Wireless Extensions + bool Wireless LAN drivers (non-hamradio) + select WIRELESS_EXT ---help--- Support for wireless LANs and everything having to do with radio, but not with amateur radio or FM broadcasting. - Saying Y here also enables the Wireless Extensions (creates - /proc/net/wireless and enables iwconfig access). The Wireless - Extension is a generic API allowing a driver to expose to the user - space configuration and statistics specific to common Wireless LANs. - The beauty of it is that a single set of tool can support all the - variations of Wireless LANs, regardless of their type (as long as - the driver supports Wireless Extension). Another advantage is that - these parameters may be changed on the fly without restarting the - driver (or Linux). If you wish to use Wireless Extensions with - wireless PCMCIA (PC-) cards, you need to say Y here; you can fetch - the tools from - http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html. - Some user-level drivers for scarab devices which don't require special kernel support are available from ftp://shadow.cabi.net/pub/Linux/. diff -u -p linux/net/ieee80211/Kconfig-j1 linux/net/ieee80211/Kconfig --- linux/net/ieee80211/Kconfig-j1 2005-12-05 18:14:05.0 -0800 +++ linux/net/ieee80211/Kconfig 2005-12-05 18:36:27.0 -0800 @@ -1,5 +1,6 @@ config IEEE80211 tristate Generic IEEE 802.11 Networking Stack + select WIRELESS_EXT ---help--- This option enables the hardware independent IEEE 802.11 networking stack. diff -u -p linux/net/Kconfig.j1 linux/net/Kconfig --- linux/net/Kconfig.j12005-12-05 18:35:54.0 -0800 +++ linux/net/Kconfig 2005-12-05 18:36:16.0 -0800 @@ -214,6 +214,24 @@ endmenu source net/ax25/Kconfig source net/irda/Kconfig source net/bluetooth/Kconfig + +config WIRELESS_EXT + bool Wireless Extensions API (802.11 and more) + ---help--- + Saying Y here enables the Wireless Extensions (creates + /proc/net/wireless and enables iwconfig access). The Wireless + Extension is a generic API allowing a driver to expose to the user + space configuration and statistics specific to common Wireless LANs. + The beauty of it is that a single set of tool can support all the + variations of Wireless LANs, regardless of their type (as long as + the driver supports Wireless Extension). Another advantage is that + these parameters may be changed on the fly without restarting the + driver (or Linux). + If you wish to use Wireless Extensions with wireless cards or with + the Generic IEEE 802.11 Networking Stack, you need to say Y here; + you can fetch the tools from + http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html. + source net/ieee80211/Kconfig endif # if NET diff -u -p linux/drivers/net/wireless/wavelan_cs.p.j1.h linux/drivers/net/wireless/wavelan_cs.p.h --- linux/drivers/net/wireless/wavelan_cs.p.j1.h2005-12-05 18:20:45.0 -0800 +++ linux/drivers/net/wireless/wavelan_cs.p.h 2005-12-05 18:21:22.0 -0800 @@ -99,7 +99,7 @@ * caracteristics of the hardware in a standard way and support for * applications for taking advantage of it (like Mobile IP). * - * You will need to enable the CONFIG_NET_RADIO define in the kernel + * You will need to enable the CONFIG_WIRELESS_EXT define in the kernel * configuration to enable the wireless extensions (this is the one * giving access to the radio network device choice). * @@ -441,7 +441,7 @@ #include linux/fcntl.h #include linux/ethtool.h -#ifdef CONFIG_NET_RADIO +#ifdef CONFIG_WIRELESS_EXT #include linux/wireless.h/* Wireless extensions */ #include net/iw_handler.h/* New driver API */ #endif diff -u -p linux/drivers/net/wireless/netwave_cs.j1.c linux/drivers/net/wireless/netwave_cs.c
Re: [IPVS] remove dead code
From: Horms [EMAIL PROTECTED] Date: Tue, 6 Dec 2005 11:18:09 +0900 ip_vs_app.c | 28 ip_vs_lblc.c | 27 --- ip_vs_lblcr.c | 27 --- ip_vs_proto_tcp.c | 22 -- 4 files changed, 104 deletions(-) Please apply Applied and scheduled for 2.6.16 inclusion. - 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
Re: [2.6 patch] net/: fix the WIRELESS_EXT abuse
On Mon, Dec 05, 2005 at 06:48:15PM -0800, Jean Tourrilhes wrote: On Mon, Dec 05, 2005 at 03:51:36PM -0800, jt wrote: Adrian Bunk wrote : Using WIRELESS_EXT instead of CONFIG_NET_RADIO is simply ugly. You are probably right that something need to be done about it, but I believe this is the wrong direction. I would prefer you to replace WIRELESS_EXT with CONFIG_WIRELESS_EXT. [...] Less talk, more patches. What do you guys think of the attached patch. Please try it... Looks good, two comments: - why is WIRELESS_EXT a user-visible option? - with this change, we do no longer have to #ifdef-guard #include's Jean cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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
[PATCH 0/3] TCP_Vegas: fix RTT measurement
Vegas RTT measurement currently seems quite broken. I've identified three issues. 1) The reseting the rtt stats is for every call to cong_avoid rather than at the end of the rtt. 2) Also, timestamping is being performed after the skb clone, leading to non-sensical RTT estimates. The patch below fixes this by timestamping the original skbs before calling tcp_transmit_skb. Timestamping is now done everywhere where skb-when is set in tcp_output.c. 3) The measuring of the RTT inside tcp_cong_avoid is redundent as far as I can tell. This call is made (with the micro second resolution) just prior to the call to tcp_vegas_cong_avoid Thomas Young - 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
Re: [PATCH 1/3] TCP_Vegas: stop resetting rtt every ack
From: Tom Young [EMAIL PROTECTED] Date: Tue, 06 Dec 2005 15:37:22 +1100 Move the resetting of rtt measurements to inside the once per RTT block of code. Signed-off-by: Thomas Young [EMAIL PROTECTED] Stephen changed this purposefully in this change: diff-tree 7faffa1c7fb9b8e8917e3225d4e2638270c0a48b (from 2d2abbab63f6726a147ae61ada39bf2c9ee0db9a) Author: Stephen Hemminger [EMAIL PROTECTED] Date: Thu Nov 10 17:07:24 2005 -0800 [TCP]: add tcp_slow_start helper Move all the code that does linear TCP slowstart to one inline function to ease later patch to add ABC support. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] Signed-off-by: David S. Miller [EMAIL PROTECTED] But it does look like an unintended change. Stephen? - 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
Re: [PATCH 2/3] TCP_Vegas: timestamp before clone
From: Tom Young [EMAIL PROTECTED]
Date: Tue, 06 Dec 2005 15:38:39 +1100
Do timestamping before cloneing.
This fixes the bug where the timestamp was performed in tcp_transmit_skb
on
the cloned skb leading to the timestamp being lost.
Signed-off-by: Thomas Young [EMAIL PROTECTED]
Excellent catch.
Why don't we do it in one place, tcp_transmit_skb(), so we don't have
to duplicate this logic in all the call sites? Something like the
patch below.
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 010f996..372f6ca 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -262,123 +262,140 @@ static __inline__ u16 tcp_select_window(
* We are working here with either a clone of the original
* SKB, or a fresh unique copy made by the retransmit engine.
*/
-static int tcp_transmit_skb(struct sock *sk, struct sk_buff *skb)
+static int tcp_transmit_skb(struct sock *sk, struct sk_buff *skb, int
clone_it, gfp_t gfp_mask)
{
- if (skb != NULL) {
- const struct inet_connection_sock *icsk = inet_csk(sk);
- struct inet_sock *inet = inet_sk(sk);
- struct tcp_sock *tp = tcp_sk(sk);
- struct tcp_skb_cb *tcb = TCP_SKB_CB(skb);
- int tcp_header_size = tp-tcp_header_len;
- struct tcphdr *th;
- int sysctl_flags;
- int err;
+ const struct inet_connection_sock *icsk = inet_csk(sk);
+ struct inet_sock *inet;
+ struct tcp_sock *tp;
+ struct tcp_skb_cb *tcb;
+ int tcp_header_size;
+ struct tcphdr *th;
+ int sysctl_flags;
+ int err;
+
+ BUG_ON(!skb || !tcp_skb_pcount(skb));
+
+ /* If congestion control is doing timestamping, we must
+* take such a timestamp before we potentially clone/copy.
+*/
+ if (icsk-icsk_ca_ops-rtt_sample)
+ __net_timestamp(skb);
- BUG_ON(!tcp_skb_pcount(skb));
+ if (likely(clone_it)) {
+ if (unlikely(skb_cloned(skb)))
+ skb = pskb_copy(skb, gfp_mask);
+ else
+ skb = skb_clone(skb, gfp_mask);
+ if (unlikely(!skb))
+ return -ENOBUFS;
+ }
+
+ inet = inet_sk(sk);
+ tp = tcp_sk(sk);
+ tcb = TCP_SKB_CB(skb);
+ tcp_header_size = tp-tcp_header_len;
#define SYSCTL_FLAG_TSTAMPS0x1
#define SYSCTL_FLAG_WSCALE 0x2
#define SYSCTL_FLAG_SACK 0x4
- /* If congestion control is doing timestamping */
- if (icsk-icsk_ca_ops-rtt_sample)
- __net_timestamp(skb);
-
- sysctl_flags = 0;
- if (tcb-flags TCPCB_FLAG_SYN) {
- tcp_header_size = sizeof(struct tcphdr) + TCPOLEN_MSS;
- if(sysctl_tcp_timestamps) {
- tcp_header_size += TCPOLEN_TSTAMP_ALIGNED;
- sysctl_flags |= SYSCTL_FLAG_TSTAMPS;
- }
- if(sysctl_tcp_window_scaling) {
- tcp_header_size += TCPOLEN_WSCALE_ALIGNED;
- sysctl_flags |= SYSCTL_FLAG_WSCALE;
- }
- if(sysctl_tcp_sack) {
- sysctl_flags |= SYSCTL_FLAG_SACK;
- if(!(sysctl_flags SYSCTL_FLAG_TSTAMPS))
- tcp_header_size +=
TCPOLEN_SACKPERM_ALIGNED;
- }
- } else if (tp-rx_opt.eff_sacks) {
- /* A SACK is 2 pad bytes, a 2 byte header, plus
-* 2 32-bit sequence numbers for each SACK block.
-*/
- tcp_header_size += (TCPOLEN_SACK_BASE_ALIGNED +
- (tp-rx_opt.eff_sacks *
TCPOLEN_SACK_PERBLOCK));
- }
+ sysctl_flags = 0;
+ if (unlikely(tcb-flags TCPCB_FLAG_SYN)) {
+ tcp_header_size = sizeof(struct tcphdr) + TCPOLEN_MSS;
+ if(sysctl_tcp_timestamps) {
+ tcp_header_size += TCPOLEN_TSTAMP_ALIGNED;
+ sysctl_flags |= SYSCTL_FLAG_TSTAMPS;
+ }
+ if (sysctl_tcp_window_scaling) {
+ tcp_header_size += TCPOLEN_WSCALE_ALIGNED;
+ sysctl_flags |= SYSCTL_FLAG_WSCALE;
+ }
+ if (sysctl_tcp_sack) {
+ sysctl_flags |= SYSCTL_FLAG_SACK;
+ if (!(sysctl_flags SYSCTL_FLAG_TSTAMPS))
+ tcp_header_size += TCPOLEN_SACKPERM_ALIGNED;
+ }
+ } else if (unlikely(tp-rx_opt.eff_sacks)) {
+ /* A SACK is 2 pad bytes, a 2 byte header, plus
+* 2 32-bit sequence numbers for each SACK block.
+*/
+ tcp_header_size +=
Re: [PATCH 3/3] TCP_Vegas: Remove extra call to tcp_vegas_rtt_calc
From: Tom Young [EMAIL PROTECTED] Date: Tue, 06 Dec 2005 15:40:57 +1100 Remove unneeded call to tcp_vegas_rtt_calc. The more accurate microsecond value has already been registered prior to calling tcp_vegas_cong_avoid. Signed-off-by: Thomas Young [EMAIL PROTECTED] This patch pretty much looks ok, will just wait for an ACK from Stephen. In general, the vegas implementation seems to have been in a quite broken state. Are you doing real testing of this cwnd module or is this all from code inspection? Thanks a lot. - 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
Re: [PATCH 3/3] TCP_Vegas: Remove extra call to tcp_vegas_rtt_calc
On Mon, 2005-12-05 at 21:43 -0800, David S. Miller wrote: From: Tom Young [EMAIL PROTECTED] Date: Tue, 06 Dec 2005 15:40:57 +1100 Remove unneeded call to tcp_vegas_rtt_calc. The more accurate microsecond value has already been registered prior to calling tcp_vegas_cong_avoid. Signed-off-by: Thomas Young [EMAIL PROTECTED] This patch pretty much looks ok, will just wait for an ACK from Stephen. In general, the vegas implementation seems to have been in a quite broken state. Are you doing real testing of this cwnd module or is this all from code inspection? Thanks a lot. - 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 Mostly testing, I'm experementing with a vegas fork that uses queing delay feedback from routers to replace baseRTT. I noticed with 2.6.14 that the rtt's were all 0. Updating to the latest linus tree yesterday got the current situation where the rtts were 'now'. Thanks, Tom - 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
Re: Broadcom 43xx first results
Hi. On Mon, 2005-12-05 at 13:46 -0500, Jeff Garzik wrote: Although I'm a bit biased towards MadWifi, I'd second your suggestion to make use of the Devicescape code. The benefit of having a fully-blown 802.11 stack in the kernel that drivers can make use of has been discussed before, so I won't go into that yet again. Use the stack that's already in the kernel. Sorry, that was my bad. I thought that the Devicescape code found its way to the kernel (didn't follow the discussion some months ago too closely). Although I think there probably are better alternatives to the 802.11 stack that is in the kernel right now, having a central 802.11 stack at all is a great improvement that should be used where possible. Encouraging otherwise hinders continued wireless progress under Linux. That depends. If the encouraging is about an alternative, more complete and superior 802.11 stack for Linux which could be integrated with less effort than extending the existing code, that should be worth to talk about. Please note that I'm not refering here to any of the related suggestions which have been made during the past months - it's a general statement. Bye, Mike - 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
