Re: [PATCH 2/2] ipg: redundancy with mii.h
Francois Romieu wrote: ipg: remove forward declarations It makes no sense in a new driver. Signed-off-by: Francois Romieu <[EMAIL PROTECTED]> Ack. ipg: replace #define with enum Added some underscores to improve readability. Signed-off-by: Francois Romieu <[EMAIL PROTECTED]> Nack. Register names in code should match those used in the documentation (even if they are a bit unreadable). Though I will conceed that the available datasheet doesn't actually describe the majority of the registers. ipg: removal of useless #defines IPG_TX_NOTBUSY apart (one occurence in ipg.c), the #defines appear nowhere in the sources. Ack. ipg: redundancy with mii.h - take II Replace a bunch of #define with their counterpart from mii.h It is applied to the usual MII registers this time. Ack. - 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: au1000_etc.c phylib rewrite
On Wed, May 03, 2006 at 06:34:16PM +0200, Herbert Valerio Riedel wrote: > while at it, does anyone happen to know what the phy-addr/MAC assignment > on the XXS1500 is? Nope. > but one thing that seems strange to me; CONFIG_BCM5222_DUAL_PHY doesn't > seem to be defined anywhere; shouldn't that be at least defined in some > Kconfig file, especially if the XXS1550 board is supposed to make use of > it? Hmm, I do recall submitting a patch previously that added 'select BCM5222_DUAL_PHY' for the XXS1500 unit. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpGtiE8Q10vb.pgp Description: PGP signature
Re: [PATCH] DECnet: Fix level1 router hello
From: Patrick Caulfield <[EMAIL PROTECTED]> Date: Thu, 27 Apr 2006 13:37:23 +0100 > This patch fixes hello messages sent when a node is a level 1 router. Slightly > contrary to the spec (maybe) VMS ignores hello messages that do not name > level2 routers that it also knows about. > > So, here we simply name all the routers that the node knows about rather just > other level1 routers. > (I hope the patch is clearer than the description. sorry). > > Patrick > > Signed-off-by: Patrick Caulfield <[EMAIL PROTECTED]> Applied, thanks Patrick. - 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: [TCP]: Fix sock_orphan dead lock
From: Herbert Xu <[EMAIL PROTECTED]> Date: Sat, 29 Apr 2006 23:13:20 +1000 > On Sat, Apr 29, 2006 at 09:15:07PM +1000, herbert wrote: > > > > Unfortunately this is only true for TCP. All of the connectionless > > protocols use the callback lock without the socket lock so it does > > still serve a purpose. > > > > I'd be happy to see your patch included. > > I've just changed my mind :) Instead of disabling BH on the read_lock > callers, we can instead move sock_orphan outside bh_lock_sock. > > [TCP]: Fix sock_orphan dead lock Ok, it took me a while to review this one as verifying such a set of changes is always tricky, but looks good! Applied, 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 2/3] Eleminate HZ from NET/ROM kernel interfaces
From: Ralf Baechle <[EMAIL PROTECTED]> Date: Sat, 29 Apr 2006 15:16:13 +0100 > Convert all NET/ROM sysctl time values from jiffies to ms as units. > > Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]> Applied. - 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] Eleminate HZ from ROSE kernel interfaces
From: Ralf Baechle <[EMAIL PROTECTED]> Date: Sat, 29 Apr 2006 15:19:24 +0100 > Convert all ROSE sysctl time values from jiffies to ms as units. > > Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]> Applied. - 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] Eleminate HZ from AX.25 kernel interfaces
From: Ralf Baechle DL5RB <[EMAIL PROTECTED]> Date: Sat, 29 Apr 2006 15:12:44 +0100 > Convert all AX.25 sysctl time values from jiffies to ms as units. > > Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]> Applied. - 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: [ROSE] Fix routing table locking in rose_remove_neigh.
From: Ralf Baechle <[EMAIL PROTECTED]> Date: Sat, 29 Apr 2006 14:31:41 +0100 > The locking rule for rose_remove_neigh() are that the called needs to > hold rose_neigh_list_lock, so we better don't take it yet again in > rose_neigh_list_lock. > > Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]> Applied, thanks. - 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: [AX.25] Move AX.25 symbol exports
From: Ralf Baechle <[EMAIL PROTECTED]> Date: Sat, 29 Apr 2006 14:40:23 +0100 > Move AX.25 symbol exports to next to their definitions where they're > supposed to be these days. > > Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]> Applied. - 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: [HAMRADIO] Remove remaining SET_MODULE_OWNER calls from hamradio drivers.
From: Ralf Baechle DL5RB <[EMAIL PROTECTED]> Date: Sat, 29 Apr 2006 15:34:13 +0100 > Signed-off-by: Ralf Baechle DL5RB <[EMAIL PROTECTED]> Applied. - 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: [AX25, ROSE] Remove useless SET_MODULE_OWNER calls.
From: Ralf Baechle DL5RB <[EMAIL PROTECTED]> Date: Sat, 29 Apr 2006 15:29:43 +0100 > Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]> Applied, thanks. - 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: [AX.25] Spelling fix
From: Ralf Baechle DL5RB <[EMAIL PROTECTED]> Date: Sat, 29 Apr 2006 15:24:27 +0100 > Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]> Applied. - 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: [ROSE] Remove useless prototype for rose_remove_neigh().
From: Ralf Baechle <[EMAIL PROTECTED]> Date: Sat, 29 Apr 2006 14:25:53 +0100 > Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]> Applied, thanks. - 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] Rough VJ Channel Implementation - vj_core.patch
On Thursday 27 April 2006 16:25, you wrote: > So the idea in your scheme is to give the buffer pools to the NIC > in a per-channel way via a simple descriptor table? And the u32's > are arbitrary keys that index into this descriptor table, right? > yeah - it _was_... Although since having a play with coding it into your implementation we've come up with the following: Using the descriptor table adds excess complexity for kernel buffers, and is really only useful for userspace. So instead of using descriptor tables for everything we've come up with a dynamic descriptor table scheme instead where they are used only for userspace. The move to skb-ising the buffers has made it more difficult to keep track of buffer lifetimes. Previously we were leaving the buffers in the ring until completely finished with them. The producer could reuse the buffer once the consumer head had moved on. With the graft to skb we can no longer do this unless the packets are processed serially (which is ok for socket channels, but not realistic for the default). We DID write an infrastructure to resolve this issue, although it is more complex than the dynamic descriptor scheme for userspace. And we want to keep this simple - right? Cheers, K - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: latest -stable breaks Squid
On 5/4/06, Ben Greear <[EMAIL PROTECTED]> wrote: Herbert Xu wrote: > Dave Jones <[EMAIL PROTECTED]> wrote: > >>So I pushed out an update for Fedora Core 5 users yesterday >>that moved the kernel from 2.6.16.9 to 2.6.16.13. >>I've since heard "My network performance is awful", and worse >>yet, some apps seem broken as in the report below. >> >>Anyone have any ideas ? > > > Try reverting the e1000 truesize patch. Although the fix is 100% > correct, it might have a negative impact on user-space apps with > particuarly small rcvbuf settings. Prior to the fix, due to the > incorrect accounting we are essentially enlarging rcvbuf by as much > as 10 times. At least one of the reports shows problems with non e1000 NICs, so it's probably not just the e1000 change. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190620 Ben Wouldn't it be more likely commit 5d0b6f2bdaf7e016e750cd24164a241512d968a3 as this touches net/ipv4/tcp_output.c and is also in same general area? -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand - 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
Fw: [Bugme-new] [Bug 6484] New: dropouts with user mode PPPoE
Begin forwarded message: Date: Tue, 2 May 2006 13:28:22 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bugme-new] [Bug 6484] New: dropouts with user mode PPPoE http://bugzilla.kernel.org/show_bug.cgi?id=6484 Summary: dropouts with user mode PPPoE Kernel Version: 2.6.16 and above Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Distribution: Debian Hardware Environment: P4 Northwood, 2 GB, i875, e1000 CSA Software Environment: pppd, rp-pppoe Problem Description: ADSL connection through PPPoE occasionally stalls for 30 to 50 seconds, especially under load. During these dropouts, packets are received but none that are supposed to be sent appear on ppp0. Ethernet interface continues to work, telnet session to modem does not stall. Exhibition of the bug is not affected by: SMP or uniprocessor kernel, Hyper Threading disabled or enabled, pppd version (tested with 2.4.2 and 2.4.4b1), rp-pppoe version (tested 3.5 & 3.8). CPU load is probably not a factor either. Dropouts seem to appear more frequently when the connection is under load (large Bittorrent swarms are a good test). They can appear as soon as a few minutes after start but it also took more than 5 hours once. Most of the time, they will appear every half to one hour. Problem does not occur with 2.6.15.7 or earlier. Second system with AMD64 SanDiego & NForce4 is not affected, will try to match configuration as closely as possible and retest. Kernel mode PPPoE using the rp-pppoe plugin does also not exhibit the bug. 2.6.17-rc3 .config: http://jawad.org/.config --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - 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: latest -stable breaks Squid
Herbert Xu wrote: Dave Jones <[EMAIL PROTECTED]> wrote: So I pushed out an update for Fedora Core 5 users yesterday that moved the kernel from 2.6.16.9 to 2.6.16.13. I've since heard "My network performance is awful", and worse yet, some apps seem broken as in the report below. Anyone have any ideas ? Try reverting the e1000 truesize patch. Although the fix is 100% correct, it might have a negative impact on user-space apps with particuarly small rcvbuf settings. Prior to the fix, due to the incorrect accounting we are essentially enlarging rcvbuf by as much as 10 times. At least one of the reports shows problems with non e1000 NICs, so it's probably not just the e1000 change. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190620 Ben Cheers, -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - 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: latest -stable breaks Squid
Dave Jones <[EMAIL PROTECTED]> wrote:
>
> So I pushed out an update for Fedora Core 5 users yesterday
> that moved the kernel from 2.6.16.9 to 2.6.16.13.
> I've since heard "My network performance is awful", and worse
> yet, some apps seem broken as in the report below.
>
> Anyone have any ideas ?
Try reverting the e1000 truesize patch. Although the fix is 100%
correct, it might have a negative impact on user-space apps with
particuarly small rcvbuf settings. Prior to the fix, due to the
incorrect accounting we are essentially enlarging rcvbuf by as much
as 10 times.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: latest -stable breaks Squid
On Wed, May 03, 2006 at 05:19:15PM -0400, Dave Jones wrote: > So I pushed out an update for Fedora Core 5 users yesterday > that moved the kernel from 2.6.16.9 to 2.6.16.13. > I've since heard "My network performance is awful", and worse > yet, some apps seem broken as in the report below. Further problems found (not all network related, but there does seem to be a pattern amongst some of them) can be seen at http://tinyurl.com/o7uqj Dave -- http://www.codemonkey.org.uk - 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/2] ipg: redundancy with mii.h
Pekka J Enberg <[EMAIL PROTECTED]> : [...] > maintain the tree, I can send you my patches so you can recreate the full > history. The first steps were produced by quilt on the original > out-of-tree driver, though, so they're probably not helpful. It will be welcome. I have added a few little things (changelog below). Next step will probably be some mii/ethtool stuff. The branch 'netdev-ipg' is available at: git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git. Serie of patches (ala 'git format-patch'): http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.17-rc3/ip1000a/ All-in-one patch: http://www.fr.zoreil.com/people/francois/misc/20060504-2.6.17-rc3-git-ip1000-test.patch ChangeLog from yesterday version: commit 8b0a8db32d1ac6e9bc23300a6a0533b4d7e251e3 Author: Francois Romieu <[EMAIL PROTECTED]> Date: Thu May 4 00:29:59 2006 +0200 ipg: remove forward declarations It makes no sense in a new driver. Signed-off-by: Francois Romieu <[EMAIL PROTECTED]> commit 65940e5e0ab88d92fbac0f96b5d46ddfbd5cfa93 Author: Francois Romieu <[EMAIL PROTECTED]> Date: Thu May 4 00:04:57 2006 +0200 ipg: replace #define with enum Added some underscores to improve readability. Signed-off-by: Francois Romieu <[EMAIL PROTECTED]> commit ab87a106690d6eaba4b7426fb074270e2e503e40 Author: Francois Romieu <[EMAIL PROTECTED]> Date: Wed May 3 22:51:16 2006 +0200 ipg: removal of useless #defines IPG_TX_NOTBUSY apart (one occurence in ipg.c), the #defines appear nowhere in the sources. Signed-off-by: Francois Romieu <[EMAIL PROTECTED]> commit ef7bfd886bc436d14649e962edb6f5189cc4dcac Author: Francois Romieu <[EMAIL PROTECTED]> Date: Wed May 3 22:44:47 2006 +0200 ipg: redundancy with mii.h - take II Replace a bunch of #define with their counterpart from mii.h It is applied to the usual MII registers this time. Signed-off-by: Francois Romieu <[EMAIL PROTECTED]> -- 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
Re: netlink+ARP+CLIP == broken,
On Wed, 03 May 2006 22:32:39 +0100
Simon Kelley <[EMAIL PROTECTED]> wrote:
> Both net/ipv4/arp.c and net/arm/clip.c create neighbour tables with
> family == AF_INET. For most purposes this is fine, since the two modules
> each hold a pointer to their table and pass it into the neigh_* functions.
>
> A problem arises in neigh_add, which is called by the rtnetlink code and
> which iterates through all the neighbour tables looking for the first
> one with the correct family. Since there are two different tables with
> family == AF_INET, sometimes it picks the wrong one.
>
> This leads to the situation where sending a RTM_NEWNEIGH message via
> netlink can generate an ignored and useless entry in the clip table,
> whilst the not affecting another entry in the ARP table, both entries
> for the same IP.
>
> Viz:
> sid:~# ip neigh
> 192.168.3.40 dev eth0 lladdr 52:54:00:12:34:59 REACHABLE
> 192.168.3.40 dev eth0 FAILED
>
>
> It's not immediately obvious how to fix this in a conceptually clean
> manner: neighbour tables are not associated with single netdevices, and
> they don't carry an address-type field. Given a {IP,lladdr,device}
> triple, its easy to determine if the device is ether-like or CLIP, but
> then the update call would have to go via the ARP and CLIP modules,
> instead of direct to the neighbour module in an address independent way.
> New address types would need further additions to the netlink/neighbour
> code.
>
> OTOH there are several obvious hacks that will fix the immediate
> problem. I'm happy to provide a patch implementing one if that's desired.
>
> Looking again, I think this is also a security hole, since the CLIP code
> keeps a whole struct including pointers in the neighbour table entry
> where ARP has the MAC address. So this might provide a way to poke
> arbitrary pointers into the kernel via RTM_NEWNEIGH. Only for root, though.
>
This was fixed in 2.6.16.6 and current 2.6.17
-
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
netlink+ARP+CLIP == broken,
Both net/ipv4/arp.c and net/arm/clip.c create neighbour tables with
family == AF_INET. For most purposes this is fine, since the two modules
each hold a pointer to their table and pass it into the neigh_* functions.
A problem arises in neigh_add, which is called by the rtnetlink code and
which iterates through all the neighbour tables looking for the first
one with the correct family. Since there are two different tables with
family == AF_INET, sometimes it picks the wrong one.
This leads to the situation where sending a RTM_NEWNEIGH message via
netlink can generate an ignored and useless entry in the clip table,
whilst the not affecting another entry in the ARP table, both entries
for the same IP.
Viz:
sid:~# ip neigh
192.168.3.40 dev eth0 lladdr 52:54:00:12:34:59 REACHABLE
192.168.3.40 dev eth0 FAILED
It's not immediately obvious how to fix this in a conceptually clean
manner: neighbour tables are not associated with single netdevices, and
they don't carry an address-type field. Given a {IP,lladdr,device}
triple, its easy to determine if the device is ether-like or CLIP, but
then the update call would have to go via the ARP and CLIP modules,
instead of direct to the neighbour module in an address independent way.
New address types would need further additions to the netlink/neighbour
code.
OTOH there are several obvious hacks that will fix the immediate
problem. I'm happy to provide a patch implementing one if that's desired.
Looking again, I think this is also a security hole, since the CLIP code
keeps a whole struct including pointers in the neighbour table entry
where ARP has the MAC address. So this might provide a way to poke
arbitrary pointers into the kernel via RTM_NEWNEIGH. Only for root, though.
Cheers,
Simon.
-
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
latest -stable breaks Squid
So I pushed out an update for Fedora Core 5 users yesterday that moved the kernel from 2.6.16.9 to 2.6.16.13. I've since heard "My network performance is awful", and worse yet, some apps seem broken as in the report below. Anyone have any ideas ? Dave -- http://www.codemonkey.org.uk --- Begin Message --- Hi folks! Just installed the new kernel 2.6.16-1.2107_FC5 (32-bit, i686), and everything seems to work fine -- except Squid (not matter if I use the one that ships with FC5 or my own). No problem with small data objects (a few kilobytes). telnet localhost 3128 GET http://www.kirchwitz.de/test.html HTTP/1.0 Large data objects won't work. According to ethereal, the data is loaded successfully. And I also find the complete objects in /var/spool/squid, but the data is not output to the application: telnet localhost 3128 GET http://www.heise.de/ HTTP/1.0 After a few kilobytes, the stream suddenly stops. Sometimes, Squid doesn't do any output at all, although the object is in the cache. With the previous kernel 2.6.16-1.2096_FC5 all is well. What has changed in the kernel that makes Squid break so hardly? Maybe other applications are affected as well. Don't know yet. The error with squid was simply very obvious. ;-) Greetings, Andreas -- fedora-list mailing list [EMAIL PROTECTED] To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list --- End Message ---
Re: [PATCH 2/3] ipg: leaks in ipg_probe
Hi Pekka, On May 02 at 10:04:47, Pekka Enberg wrote: > > No clear idea but it matches the significant part of the BAR register > > for the 256 bytes of I/O space that the device uses. > > OK. David & David, would appreciate if either you could give the patch a > spin with Francois' changes. Thanks. I applied latest Francois patch and the changes (and specially the dma changes) seems to be ok. On the other hand i'm having some problems. Nothing related to the patches, because it happens with the original driver too: After some time using it, the driver becomes unresponsive and i need to restart the interface and/or unload-load the ipg module. I'd need to compile it with debug enabled when i have some time to see what it's going on... cheers, -- David Gómez Jabber ID: [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: VJ Channel API - driver level (PATCH)
David S. Miller wrote: > From: Evgeniy Polyakov <[EMAIL PROTECTED]> > Date: Wed, 3 May 2006 22:07:40 +0400 > >> On Wed, May 03, 2006 at 08:56:23AM -0700, Caitlin Bestler > ([EMAIL PROTECTED]) wrote: I'd expect high end NIC ASICs to implement rx steering based upon some sort of hash (for load balancing), as well as explicit "1:1" steering between a sw channel and a hw channel. Both options for channel configuration are present in the driver interface. If netfilter assists can be done in hardware, I agree the driver interface will need to add support for these - otherwise, netfilter processing will stay above the driver. >>> >>> Even if the hardware cannot fully implement netfilter rules there is >>> still value in having an interface that documents exactly how much >>> filtering a given piece of hardware can do. >>> There is no point in having the kernel repeat packet classifications >>> that have already been done by the NIC. >> >> Please do not suppose that vj channel must rely on underlaying >> hardware. > > I am not. I am just saying that it is futile to build > hardware that cannot handle netfilter at least to some > extent, because this will result in HW net channels being > disabled for %99 of real users which makes the hardware just a waste. Or netfilters being disabled, which would be just as bad or worse. The kernel and hardware need to co-operate so that users are not asked to make artificial choices between performance and security. - 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: VJ Channel API - driver level (PATCH)
From: Evgeniy Polyakov <[EMAIL PROTECTED]> Date: Wed, 3 May 2006 22:07:40 +0400 > On Wed, May 03, 2006 at 08:56:23AM -0700, Caitlin Bestler ([EMAIL PROTECTED]) > wrote: > > > I'd expect high end NIC ASICs to implement rx steering based > > > upon some sort of hash (for load balancing), as well as > > > explicit "1:1" steering between a sw channel and a hw > > > channel. Both options for channel configuration are present > > > in the driver interface. > > > If netfilter assists can be done in hardware, I agree the > > > driver interface will need to add support for these - > > > otherwise, netfilter processing will stay above the driver. > > > > > > > > > > Even if the hardware cannot fully implement netfilter rules > > there is still value in having an interface that documents > > exactly how much filtering a given piece of hardware can do. > > There is no point in having the kernel repeat packet classifications > > that have already been done by the NIC. > > Please do not suppose that vj channel must rely on underlaying hardware. I am not. I am just saying that it is futile to build hardware that cannot handle netfilter at least to some extent, because this will result in HW net channels being disabled for %99 of real users which makes the hardware just a waste. - 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: VJ Channel API - driver level (PATCH)
From: "Leonid Grossman" <[EMAIL PROTECTED]> Date: Wed, 3 May 2006 09:56:18 -0400 > Do you have suggestions on potential hardware assists/offloads for > netfilter? We don't know yet what things will look like, that's why we shouldn't be defining APIs and I cannot give any such advice yet. - 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
sky2 1.3-rc1
Here is a new version that addresses some of the outstanding bugs. * There was a race in receive processing that would cause hang * Some more support for Yukon Ultra found in dual-core Centrino laptops (I want one of these). It does not fix the problems with dual port cards corrupting receive data (and possibly memory). http://developer.osdl.org/shemminger/prototypes/sky2-1.3-rc1.tar.bz2 If this works for most people, I'll post as separate patches for 2.6.17 tomorrow. - 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] bcm43xx-d80211: measure the channel change time
Measure the channel change time with the
bcm43xx tsf timer and remove the guesswork constant. ;)
Tests on my 4306 show that the time comes damn
close to reality.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
2006-05-03 18:12:27.0 +0200
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
2006-05-03 20:51:24.0 +0200
@@ -354,6 +354,33 @@
bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD, status);
}
+static void bcm43xx_measure_channel_change_time(struct bcm43xx_private *bcm)
+{
+ struct bcm43xx_radioinfo *radio;
+ u64 start, stop;
+ unsigned long flags;
+ u8 oldchan, testchan;
+
+ /* We (ab)use the bcm43xx TSF timer to measure the time needed
+* to switch channels. This information is handed over to
+* the ieee80211 subsystem.
+* Time is measured in microseconds.
+*/
+
+ bcm43xx_lock_mmio(bcm, flags);
+ radio = bcm43xx_current_radio(bcm);
+ oldchan = radio->channel;
+ testchan = (oldchan == 6) ? 7 : 6;
+ bcm43xx_tsf_read(bcm, &start);
+ bcm43xx_radio_selectchannel(bcm, testchan, 0);
+ bcm43xx_tsf_read(bcm, &stop);
+ bcm43xx_radio_selectchannel(bcm, oldchan, 0);
+ bcm43xx_unlock_mmio(bcm, flags);
+
+ assert(stop > start);
+ bcm->ieee->channel_change_time = stop - start;
+}
+
static
void bcm43xx_macfilter_set(struct bcm43xx_private *bcm,
u16 offset,
@@ -3706,6 +3733,7 @@
dprintk(KERN_INFO PFX "80211 cores initialized\n");
bcm43xx_setup_modes(bcm);
bcm43xx_security_init(bcm);
+ bcm43xx_measure_channel_change_time(bcm);
ieee80211_update_hw(bcm->net_dev, bcm->ieee);
ieee80211_netif_oper(bcm->net_dev, NETIF_ATTACH);
ieee80211_netif_oper(bcm->net_dev, NETIF_START);
@@ -4329,7 +4357,6 @@
ieee->host_gen_beacon = 1;
ieee->rx_includes_fcs = 1;
ieee->monitor_during_oper = 1;
- ieee->channel_change_time = 2;
ieee->tx = bcm43xx_net_hard_start_xmit;
ieee->open = bcm43xx_net_open;
ieee->stop = bcm43xx_net_stop;
--
Greetings Michael.
-
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: VJ Channel API - driver level (PATCH)
On Wed, 3 May 2006 11:12:15 -0700 "Caitlin Bestler" <[EMAIL PROTECTED]> wrote: > Evgeniy Polyakov wrote: > > On Wed, May 03, 2006 at 08:56:23AM -0700, Caitlin Bestler > > ([EMAIL PROTECTED]) wrote: > >>> I'd expect high end NIC ASICs to implement rx steering based upon > >>> some sort of hash (for load balancing), as well as explicit "1:1" > >>> steering between a sw channel and a hw channel. Both options for > >>> channel configuration are present in the driver interface. > >>> If netfilter assists can be done in hardware, I agree the driver > >>> interface will need to add support for these - otherwise, netfilter > >>> processing will stay above the driver. > >>> > >>> > >> > >> Even if the hardware cannot fully implement netfilter rules there is > >> still value in having an interface that documents exactly how much > >> filtering a given piece of hardware can do. > >> There is no point in having the kernel repeat packet classifications > >> that have already been done by the NIC. > > > > Please do not suppose that vj channel must rely on > > underlaying hardware. > > New interface MUST work better or at least not worse than > > existing skb queueing for majority of users, and I doubt > > users with netfilter capable hardware are there. > > It is only some hint to the SW, not rules, that hardware can provide. > > The best would be ipv4/ipv6 hashing, and I think it is enough. > > I agree. I was just stating that *if* there is direct hardware > support then the software should be enabled to skip > redundant checks. What I'm suggesting is really the > equivalent of knowing whether the hardware generates > or checks CRCs and TCP checksums. Don't mandate > the feature, just have the option to avoid redundant work. > Also like mulitcast filtering, you need to allow for the partial match case. If hardware can do some of the work, it is helps. - 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: VJ Channel API - driver level (PATCH)
In article <[EMAIL PROTECTED]> (at Wed, 3 May 2006 22:07:40 +0400), Evgeniy Polyakov <[EMAIL PROTECTED]> says: > > Even if the hardware cannot fully implement netfilter rules > > there is still value in having an interface that documents > > exactly how much filtering a given piece of hardware can do. > > There is no point in having the kernel repeat packet classifications > > that have already been done by the NIC. > > Please do not suppose that vj channel must rely on underlaying hardware. > New interface MUST work better or at least not worse than existing skb > queueing for majority of users, and I doubt users with netfilter capable > hardware are there. > It is only some hint to the SW, not rules, that hardware can provide. > The best would be ipv4/ipv6 hashing, and I think it is enough. And, I believe that, if a packet contains any ipv6 extension header(s), including routing header, fragmentation header, etc., we should process it in kernel as we do for now. Regards, --yoshfuji - 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 wireless-dev] d80211: Add support for user space client MLME
On Wed, May 03, 2006 at 08:10:59PM +0200, Jiri Benc wrote:
> If you really feel this is a necessary feature (although I think we
> should focus more on putting the stack to a form suitable for inclusion
> in the kernel than on adding new features now), what about making the
> wmaster0ap interface appear only when the device is switched to user
> space MLME? Should I make a patch?
I think it would be nice to get this in so that both client and AP modes
can use the same mechanism (user space MLME); hostapd already needs this
wmaster0ap interface. In other words, if we do not want to see that
interface by default, we could just add a generic mechanism for
registering wmaster0ap that both hostapd and wpa_supplicant could use.
The Host AP driver (driver/net/wireless/hostap) is doing this with
PRISM2_PARAM_HOSTAPD parameter. I don't care how it's done, but some
simple mechanism would be preferred.
> I had in mind cards with large parts of MLME implemented in their
> firmware, when MLME is moved from the stack fully to userspace. Such
> cards probably won't allow you to handle e. g. scanning by switching
> channels and sending probe requests. I know, we're not going to support
> them soon, but isn't this something that will disallow the suppport at
> all?
No, move of MLME to user space should not change this at all. As an
example, wpa_supplicant supports both cases and the patch I'm working on
for getting Prism2 (full MAC for client mode) working with d80211 is
modifying the kernel side to allow this to be done. Both changes are
touching the same areas in the code, but there is no major change in
whether fullmac can be supported or not.
> > Some time ago, I sent a preliminary patch showing what kind of changes
> > are needed and this was mainly avoiding calls to some ieee80211_sta.c
> > functions.
>
> Hm, I probably missed that patch (or maybe just can't remember). Could
> you post a link or something?
http://hostap.epitest.fi/releases/testing/jkm-wireless-dev-patches.tar.gz
That is not up-to-date with wireless-dev.git anymore, though. The key
patch is d80211_fullmac_client.diff which is small enough to include
here. Please note that this is not yet complete, so consider it more an
example on what type of changes are needed.
d80211: Add support for hardware-based client MLME (fullmac)
Add support for using hardware/firmware-based client MLME (fullmac) into
the Devicescape IEEE 802.11 stack. This adds a new flag, hw_client_mlme,
for the low-level drivers to indicate that the client MLME (management
frame processing) is implemented in hardware/firmware. This disables
host-based MLME implementation for client mode.
In addition to changes in net/d80211, this patch fixes client mode for
the Prism2/2.5/3 driver in drivers/net/wireless/d80211 by using the new
mode of implementing client MLME in firmware. AP mode (Host AP) is still
using host-based MLME.
Signed-off-by: Jouni Malinen <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/d80211/prism3_hw.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/prism3_hw.c
+++ wireless-dev/drivers/net/wireless/d80211/prism3_hw.c
@@ -2931,6 +2931,7 @@ static struct ieee80211_hw prism3_hw = {
.version = IEEE80211_VERSION,
.name = "prism3",
.host_broadcast_ps_buffering = 1,
+ .hw_client_mlme = 1,
.num_modes = 1,
.num_modes = NUM_ENTRIES(prism3_hw_modes),
.modes = prism3_hw_modes,
Index: wireless-dev/include/net/d80211.h
===
--- wireless-dev.orig/include/net/d80211.h
+++ wireless-dev/include/net/d80211.h
@@ -441,7 +441,11 @@ struct ieee80211_hw {
/* 1 = low-level driver supports skb fraglist (NETIF_F_FRAGLIST), i.e.,
* more than one skb per frame */
- unsigned int fraglist;
+ unsigned int fraglist:1;
+
+ /* 0 = client MLME in host software (softmac)
+* 1 = client MLME in hardware/firmware (fullmac) */
+ unsigned int hw_client_mlme:1;
/* This is the time in us to change channels
*/
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/d80211/ieee80211_ioctl.c
@@ -1028,10 +1028,16 @@ static int ieee80211_ioctl_scan_req(stru
u8 *pos = param->u.scan_req.ssid;
int left = param_len - ((u8 *) pos - (u8 *) param);
int len = param->u.scan_req.ssid_len;
+ struct ieee80211_local *local = dev->priv;
if (left < len || len > IEEE80211_MAX_SSID_LEN)
return -EINVAL;
+ if (local->hw->hw_client_mlme) {
+ /* TODO: add local->hw->scan_req() */
+ return 0;
+ }
+
return ieee80211_sta_req_scan(dev, pos, len);
}
@@ -1053,10 +1059,17 @@ static int ieee80211_ioctl_mlme(struct n
Re: Question on e1000 patch, rx-copy-break related.
On 5/3/06, Ben Greear <[EMAIL PROTECTED]> wrote: So, as of 2.6.16.13, is the hardware stripping (SERC) enabled? Could you also let me know where this bit is defined in case I want to twiddle it myself (a quick grep for SERC in 2.6.16.13 yields nothing.) You missed a C, it's SECRC (Strip Ethernet CRC) in the RCTL register or E1000_RCTL_SECRC. - Chris - 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: Question on e1000 patch, rx-copy-break related.
Jesse Brandeburg wrote: On 5/2/06, Ben Greear <[EMAIL PROTECTED]> wrote: In commit: a292ca6efbc1f259ddfb9c902367f2588e0e8b0f to e1000_main.c, there is the change below. I am curious why the skb_put no longer subtracts ETHERNET_FCS_SIZE from the length. Is the idea that we will now always include the FCS at the end of the skb? This is a long and hairy story behind this, but there is a bit called SECRC that controls hardware stripping of the CRC. In *this* driver we turned that bit on, so that we didn't have to mess with skb->len -= 4 and the nasty negative unwrap if we were using multiple descriptors for rx. Since then, we've removed multiple descriptor rx. And after that, I've discovered that some BMCs are very unhappy if we strip CRCs using SECRC. So, my related question is: is it okay if we just always leave the CRC on the end of the data? It doesn't seem to harm anything. I believe it might mess up bridging logic if it tries to send the entire skb to a peer interface, ie cause an extra 4 bytes to be written. I know that this 'save-crc' feature did mess up my particular bridge-like thing, but that could have been just bugs in my code. Also, if the CRC data is there, but it is never 'put' into the skb, then it will be correctly ignored by the stacks, including bridging, and hacks such as my own that simply increase the skb-put by 4 bytes will work. My personal preference is to set a flag in the skb struct indicating whether or not the crc is appended (and skb_put). Then, bridging code can ignore it if needed, and sniffers and such can get the CRC in user-land. To remain backwards compat, at least the skb-put of the crc logic should default to OFF so that we don't break any existing user-land bridging logic. I have the ethtool API logic written to twiddle this save-crc behaviour if someone decides this is worthy of the kernel. Well, its a changing picture. I had planned to eventually enable the hardware to strip the CRC if we aren't connected to some kind of offboard management. We'll get there in steps. So, as of 2.6.16.13, is the hardware stripping (SERC) enabled? Could you also let me know where this bit is defined in case I want to twiddle it myself (a quick grep for SERC in 2.6.16.13 yields nothing.) Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - 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: VJ Channel API - driver level (PATCH)
Evgeniy Polyakov wrote: > On Wed, May 03, 2006 at 08:56:23AM -0700, Caitlin Bestler > ([EMAIL PROTECTED]) wrote: >>> I'd expect high end NIC ASICs to implement rx steering based upon >>> some sort of hash (for load balancing), as well as explicit "1:1" >>> steering between a sw channel and a hw channel. Both options for >>> channel configuration are present in the driver interface. >>> If netfilter assists can be done in hardware, I agree the driver >>> interface will need to add support for these - otherwise, netfilter >>> processing will stay above the driver. >>> >>> >> >> Even if the hardware cannot fully implement netfilter rules there is >> still value in having an interface that documents exactly how much >> filtering a given piece of hardware can do. >> There is no point in having the kernel repeat packet classifications >> that have already been done by the NIC. > > Please do not suppose that vj channel must rely on > underlaying hardware. > New interface MUST work better or at least not worse than > existing skb queueing for majority of users, and I doubt > users with netfilter capable hardware are there. > It is only some hint to the SW, not rules, that hardware can provide. > The best would be ipv4/ipv6 hashing, and I think it is enough. I agree. I was just stating that *if* there is direct hardware support then the software should be enabled to skip redundant checks. What I'm suggesting is really the equivalent of knowing whether the hardware generates or checks CRCs and TCP checksums. Don't mandate the feature, just have the option to avoid redundant work. - 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 wireless-dev] d80211: Add support for user space client MLME
On Wed, 3 May 2006 09:44:58 -0700, Jouni Malinen wrote: > Why do you think that this would be too early now? I agree that the > interface between kernel and user space MLME can be improved, but I see > no point in making client MLME implementation wait for that to happen. > Personally, I don't think that the wmaster#ap interface is really that > ugly, but I have nothing against this being improved if someone has time > for doing it. I just don't see it as the highest priority. On the other hand, I'm afraid it will be hard to explain to users why there are all these network interfaces (wmaster0, wmaster0ap) they shouldn't touch at all. I'm trying to reduce those interfaces as much as possible. We cannot avoid wmaster0, but we can avoid wmaster0ap. So I see the new kernel->hostapd (wpa_supplicant) interface as a rather high priority. > But there is.. I committed changes to the wpa_supplicant devel branch > for this yesterday. It seems to work fine with net/d80211 and bcm43xx > with this small patch to d80211 to allow the functionality to be moved > into user space. Oh, sorry, didn't know that. If you really feel this is a necessary feature (although I think we should focus more on putting the stack to a form suitable for inclusion in the kernel than on adding new features now), what about making the wmaster0ap interface appear only when the device is switched to user space MLME? Should I make a patch? > I have not yet heard of anyone working with details of converting the > management frame communication to use netlink. With details - no, neither have I. > > Also, I'm not sure how fullmac cards could be (potentially) supported > > with this approach. > > In the same way as with the kernel space MLME implementation.. This > does not really change regardless of where the MLME code is implemented. I had in mind cards with large parts of MLME implemented in their firmware, when MLME is moved from the stack fully to userspace. Such cards probably won't allow you to handle e. g. scanning by switching channels and sending probe requests. I know, we're not going to support them soon, but isn't this something that will disallow the suppport at all? Or do I understand it wrong? > Some time ago, I sent a preliminary patch showing what kind of changes > are needed and this was mainly avoiding calls to some ieee80211_sta.c > functions. Hm, I probably missed that patch (or maybe just can't remember). Could you post a link or something? Thanks, Jiri -- 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: VJ Channel API - driver level (PATCH)
On Wed, May 03, 2006 at 08:56:23AM -0700, Caitlin Bestler ([EMAIL PROTECTED]) wrote: > > I'd expect high end NIC ASICs to implement rx steering based > > upon some sort of hash (for load balancing), as well as > > explicit "1:1" steering between a sw channel and a hw > > channel. Both options for channel configuration are present > > in the driver interface. > > If netfilter assists can be done in hardware, I agree the > > driver interface will need to add support for these - > > otherwise, netfilter processing will stay above the driver. > > > > > > Even if the hardware cannot fully implement netfilter rules > there is still value in having an interface that documents > exactly how much filtering a given piece of hardware can do. > There is no point in having the kernel repeat packet classifications > that have already been done by the NIC. Please do not suppose that vj channel must rely on underlaying hardware. New interface MUST work better or at least not worse than existing skb queueing for majority of users, and I doubt users with netfilter capable hardware are there. It is only some hint to the SW, not rules, that hardware can provide. The best would be ipv4/ipv6 hashing, and I think it is enough. -- Evgeniy Polyakov - 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: VJ Channel API - driver level (PATCH)
Are you proposing a mechanism for the consuming end of a tx channel to support a large number of channels, or are you assuming that the number of tx channels will be small enough that simply polling them in priority order is adequate? - 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] bcm43xx-d80211: rewrite interface handling
On Wed, 3 May 2006 18:42:04 +0200, Michael Buesch wrote: > Rewrite the virtual interface handling. > With this monitor_during_oper is made possible. > > Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> Acked-by: Jiri Benc <[EMAIL PROTECTED]> -- 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: Question on e1000 patch, rx-copy-break related.
On 5/2/06, Ben Greear <[EMAIL PROTECTED]> wrote:
In commit: a292ca6efbc1f259ddfb9c902367f2588e0e8b0f
to e1000_main.c, there is the change below.
I am curious why the skb_put no longer subtracts ETHERNET_FCS_SIZE
from the length. Is the idea that we will now always include the
FCS at the end of the skb?
This is a long and hairy story behind this, but there is a bit called
SECRC that controls hardware stripping of the CRC. In *this* driver
we turned that bit on, so that we didn't have to mess with skb->len -=
4 and the nasty negative unwrap if we were using multiple descriptors
for rx.
Since then, we've removed multiple descriptor rx.
And after that, I've discovered that some BMCs are very unhappy if we
strip CRCs using SECRC.
So, my related question is: is it okay if we just always leave the CRC
on the end of the data? It doesn't seem to harm anything.
It also seems that the skb_put for the else clause is missing here, but
I think it is fixed in some later patch.
The main reason I ask is that I have a patch that enabled reception of the
FCS in 2.6.13. It used a flag to determine whether to subtract the
ETHERNET_FCS_SIZE
from length (or not, if we are capturing FCS). I am trying to figure out if
this
is still needed in the later releases.
Well, its a changing picture. I had planned to eventually enable the
hardware to strip the CRC if we aren't connected to some kind of
offboard management. We'll get there in steps.
Thanks,
Ben
@@ -3613,17 +3618,40 @@ #endif
}
}
- /* Good Receive */
- skb_put(skb, length - ETHERNET_FCS_SIZE);
+ /* code added for copybreak, this should improve
+* performance for small packets with large amounts
+* of reassembly being done in the stack */
+#define E1000_CB_LENGTH 256
+ if ((length < E1000_CB_LENGTH) &&
+ !rx_ring->rx_skb_top &&
+ /* or maybe (status & E1000_RXD_STAT_EOP) && */
+ !multi_descriptor) {
+ struct sk_buff *new_skb =
+ dev_alloc_skb(length + NET_IP_ALIGN);
+ if (new_skb) {
+ skb_reserve(new_skb, NET_IP_ALIGN);
+ new_skb->dev = netdev;
+ memcpy(new_skb->data - NET_IP_ALIGN,
+ skb->data - NET_IP_ALIGN,
+ length + NET_IP_ALIGN);
+ /* save the skb in buffer_info as good */
+ buffer_info->skb = skb;
+ skb = new_skb;
+ skb_put(skb, length);
+ }
+ }
+
+ /* end copybreak code */
-
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 wireless-dev] d80211: Add support for user space client MLME
On Wed, May 03, 2006 at 06:28:15PM +0200, Jiri Benc wrote: > It is too early for this. We need to implement some better communication > interface between kernel and hostapd (or what will implement userspace > MLME) first. The current solution, where there is some special > net_device interface (wmaster0ap) abused to dump informations to > userspace, is ugly and confusing for users. Why do you think that this would be too early now? I agree that the interface between kernel and user space MLME can be improved, but I see no point in making client MLME implementation wait for that to happen. Personally, I don't think that the wmaster#ap interface is really that ugly, but I have nothing against this being improved if someone has time for doing it. I just don't see it as the highest priority. > There is no userspace MLME implementation yet. And if one is going to be > written, I'm really convinced it should be written in a clean way. I > think Simon said he would examine a possibility to convert this stuff to > netlink - is there some progress there? But there is.. I committed changes to the wpa_supplicant devel branch for this yesterday. It seems to work fine with net/d80211 and bcm43xx with this small patch to d80211 to allow the functionality to be moved into user space. I have not yet heard of anyone working with details of converting the management frame communication to use netlink. > Also, I'm not sure how fullmac cards could be (potentially) supported > with this approach. In the same way as with the kernel space MLME implementation.. This does not really change regardless of where the MLME code is implemented. Some time ago, I sent a preliminary patch showing what kind of changes are needed and this was mainly avoiding calls to some ieee80211_sta.c functions. -- Jouni MalinenPGP id EFC895FA - 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: au1000_etc.c phylib rewrite
hello * On Tue, 2006-05-02 at 11:20 -0500, Mark Schank wrote: > At 08:23 AM 5/2/06 +0200, Herbert Valerio Riedel wrote: > >On Mon, 2006-05-01 at 15:09 -0500, Mark Schank wrote: > > > The Cogent CSB655 used the Broadcom Dual Phy. They eventually redesigned > > > the board and switched to two single Broadcom phys, but they continued to > > > control both phys through MAC0, which is the actual purpose of the > > dual-phy > > > hack. I am a user of the CSB655, so I sort of care. > > > > > > Will the new PHY framework allow a second PHY for a second MAC (MAC1) be > > > controlled from the first MAC's (MAC0) mdio interface? > > > >should'nt be a problem (as opposed to the bosporus case... see below)... > >I assume the phy-addresses on which the boarcom dual phy is configured > >are the same for all Cogent CSB655 boards? > > Dual PHY configuration: > MAC0 - phy addr 4 > MAC1 - phy addr 3 > Single PHY configuration: > MAC0 - phy addr 1 > MAC1 - phy addr 0 while at it, does anyone happen to know what the phy-addr/MAC assignment on the XXS1500 is? > >does this need to be autodetected dynamically at runtime, or can we rely > >on a compile time Kconfig-conditional to set a static phy-addr<->eth% > >d-phy mapping for this board-specific case? Or de we really need such a > >complex mii_probe() function to detect weird scenarios? :) > > The compile time Kconfig-conditional should be okay. The driver need to > handle the fact that the MAC1's phy is controlled by MAC0's mdio > interface. This means that MAC0 controller can not be disabled when the > associated eth% device is down, otherwise you lose the ability to control > MAC1's phy. ...or at least, the MAC associated with the particular MII bus should be brought up if necessary before any mdio access (that's what I'm implementing right now) but one thing that seems strange to me; CONFIG_BCM5222_DUAL_PHY doesn't seem to be defined anywhere; shouldn't that be at least defined in some Kconfig file, especially if the XXS1550 board is supposed to make use of it? btw, is the CSB655 supported at all in the 2.6 linux-mips branch, I couldn't find any mention of it in Kconfig files either? > >using static phy addr mappings would also allow for setting > >board-specific phy-irq assignments, which would then be handled by the > >phylib facilities, instead of polling the status of phy with a timer; > >(and in case we don't have any board-specific compile time setting, we > >can still fall back to search the phy-addresses for a PHY at runtime as > >the generic case) > > Will the phylib facilities handle the case where two phys share a single IRQ? afaics from the source, it doesn't handle the case of multiplexed phy notification irqs; although the interrupt is requested with the SA_SHIRQ flag, the first phy-interrupt-handler to be called already returns IRQ_HANDLED... doesn't feel right in some way ;-) > >while at it, what about that CONFIG_MIPS_BOSPORUS special case? why > >doesn't the 2nd MAC see any PHY? how is the 2nd MAC connected to the > >physical world? > > I don't have first hand knowledge of this board, but I have worked with > Kendin switches before. They have a special port that allows direct > connection of a MAC into the switch port without the use of a phy. The > MAC's MII is directly connected to the switch ports MII. So instead of this: > MAC <-> PHY <->PHY <-> Switch_Port > You have this: > MAC <-> Switch_Port > > So the MAC talks to the physical world via the switch. thx; in the meantime, I've happened to find the board schematics and the switch data-sheet in order to understand the situation better regards, hvr signature.asc Description: This is a digitally signed message part
[PATCH] bcm43xx-d80211: rewrite interface handling
Hi John,
Please apply to wireless-dev.
--
Rewrite the virtual interface handling.
With this monitor_during_oper is made possible.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
2006-04-28 16:13:40.0 +0200
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h 2006-05-03
18:02:55.0 +0200
@@ -626,10 +626,32 @@
u8 algorithm;
};
+struct bcm43xx_interface {
+ /* Opaque ID of the operating interface (!= monitor
+* interface) from the ieee80211 subsystem.
+* Do not modify.
+*/
+ int if_id;
+ /* MAC address. */
+ u8 *mac_addr;
+ /* Current BSSID (if any). */
+ u8 *bssid;
+
+ /* Interface type. (IEEE80211_IF_TYPE_XXX) */
+ int type;
+ /* Counter of active monitor interfaces. */
+ int monitor;
+ /* Is the card operating in AP, STA or IBSS mode? */
+ unsigned int operating:1;
+ /* Promisc mode active?
+* Note that (monitor != 0) implies promisc.
+*/
+ unsigned int promisc:1;
+};
+
struct bcm43xx_private {
struct ieee80211_hw *ieee;
struct ieee80211_low_level_stats ieee_stats;
- int iw_mode;
struct net_device *net_dev;
struct pci_dev *pci_dev;
@@ -653,6 +675,13 @@
short_slot:1, /* TRUE, if short slot timing is
enabled. */
firmware_norelease:1; /* Do not release the firmware. Used on
suspend. */
+ /* One physical device can have one operating interface
+* and a virtually infinite amount of monitoring interfaces.
+* This keeps track of the interfaces and the corresponding
+* hardware modes.
+*/
+ struct bcm43xx_interface interface;
+ /* Various statistics about the physical device. */
struct bcm43xx_stats stats;
/* Bus type we are connected to.
@@ -716,8 +745,6 @@
/* Informational stuff. */
char nick[IW_ESSID_MAX_SIZE + 1];
- u8 bssid[ETH_ALEN];
- int interfaces;
/* encryption/decryption */
u16 security_offset;
@@ -854,6 +881,15 @@
return bcm;
}
+/* Is the device operating in a specified mode (IEEE80211_IF_TYPE_XXX). */
+static inline
+int bcm43xx_is_mode(struct bcm43xx_private *bcm, int type)
+{
+ if (type == IEEE80211_IF_TYPE_MNTR)
+ return !!bcm->interface.monitor;
+ return (bcm->interface.operating &&
+ bcm->interface.type == type);
+}
static inline
u16 bcm43xx_read16(struct bcm43xx_private *bcm, u16 offset)
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.c
2006-04-28 16:13:40.0 +0200
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.c
2006-05-03 18:00:46.0 +0200
@@ -217,7 +217,7 @@
bcm43xx_led_blink_stop(led, 0);
continue;
case BCM43xx_LED_APTRANSFER:
- if (bcm->iw_mode == IW_MODE_MASTER) {
+ if (bcm43xx_is_mode(bcm, IEEE80211_IF_TYPE_AP)) {
if (transferring) {
interval = BCM43xx_LEDBLINK_FAST;
turn_on = 1;
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
2006-04-28 16:13:40.0 +0200
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
2006-05-03 18:12:27.0 +0200
@@ -378,18 +378,26 @@
static void bcm43xx_macfilter_clear(struct bcm43xx_private *bcm,
u16 offset)
{
- const u8 zero_addr[ETH_ALEN] = { 0 };
+ static const u8 zero_addr[ETH_ALEN] = { 0 };
bcm43xx_macfilter_set(bcm, offset, zero_addr);
}
static void bcm43xx_write_mac_bssid_templates(struct bcm43xx_private *bcm)
{
- const u8 *mac = (const u8 *)(bcm->net_dev->dev_addr);
- const u8 *bssid = bcm->bssid;
+ static const u8 zero_addr[ETH_ALEN] = { 0 };
+ const u8 *mac = NULL;
+ const u8 *bssid = NULL;
u8 mac_bssid[ETH_ALEN * 2];
int i;
+ bssid = bcm->interface.bssid;
+ if (!bssid)
+ bssid = zero_addr;
+ mac = bcm->interface.mac_addr;
+ if (!mac)
+ mac = zero_addr;
+
memcpy(mac_bssid, mac, ETH_ALEN);
memcpy(mac_bssid + ETH_ALEN, bssid, ETH_ALEN);
@@ -1438,15 +1446,15 @@
static void handle_irq_ps(struct bcm43xx_private *bcm)
{
-
Re: [PATCH wireless-dev] d80211: Add support for user space client MLME
On Tue, 2 May 2006 14:18:17 -0700, Jouni Malinen wrote: > Add a configuration option for disabling client MLME in kernel > code. This is used to enable user space MLME for client mode (e.g., > with wpa_supplicant). The kernel MLME implementation is unmodified, > but it could be removed or at least made optional in build > configuration in the future. It is too early for this. We need to implement some better communication interface between kernel and hostapd (or what will implement userspace MLME) first. The current solution, where there is some special net_device interface (wmaster0ap) abused to dump informations to userspace, is ugly and confusing for users. There is no userspace MLME implementation yet. And if one is going to be written, I'm really convinced it should be written in a clean way. I think Simon said he would examine a possibility to convert this stuff to netlink - is there some progress there? Also, I'm not sure how fullmac cards could be (potentially) supported with this approach. Thanks, Jiri -- 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: VJ Channel API - driver level (PATCH)
[EMAIL PROTECTED] wrote: >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of David S. Miller >> Sent: Tuesday, May 02, 2006 11:48 PM >> To: [EMAIL PROTECTED] >> Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org >> Subject: Re: VJ Channel API - driver level (PATCH) >> >> >> I don't think we should be defining driver APIs when we haven't even >> figured out how the core of it would even work yet. >> >> A key part of this is the netfilter bits, that will require >> non-trivial flow identification, a hash will simply not be enough, >> and it will not be allowed to not support the netfilter bits properly >> since everyone will have netfilter enabled in one way or another. > > Hi Dave, > > Do you have suggestions on potential hardware > assists/offloads for netfilter? > > I suppose some of it can be worthwhile, although in general > may be too complex to implement - especially above 1 Gig. > > I'd expect high end NIC ASICs to implement rx steering based > upon some sort of hash (for load balancing), as well as > explicit "1:1" steering between a sw channel and a hw > channel. Both options for channel configuration are present > in the driver interface. > If netfilter assists can be done in hardware, I agree the > driver interface will need to add support for these - > otherwise, netfilter processing will stay above the driver. > > Even if the hardware cannot fully implement netfilter rules there is still value in having an interface that documents exactly how much filtering a given piece of hardware can do. There is no point in having the kernel repeat packet classifications that have already been done by the NIC. - 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] d80211: bugfixes, reducing number of interfaces (again)
Following patches can be also obtained from: git://git.kernel.org/pub/scm/linux/kernel/git/jbenc/dscape.git up Jiri Benc: d80211: get rid of default management interface d80211: use alloc_netdev d80211: fix is_ieee80211_device net/d80211/ieee80211.c | 150 +++ net/d80211/ieee80211_i.h | 10 +- net/d80211/ieee80211_iface.c | 104 ++--- 3 files changed, 152 insertions(+), 112 deletions(-) -- 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 1/3] d80211: get rid of default management interface
Default management interface (wmasterXap) confuses users. It is only needed
for AP mode (and only until the new netlink interface between kernel and
hostapd is implemented).
This patch removes default management interface. When first interface is
switched to AP mode, a management interface is created automatically.
Signed-off-by: Jiri Benc <[EMAIL PROTECTED]>
---
net/d80211/ieee80211.c | 101 ++
net/d80211/ieee80211_i.h |4 +-
net/d80211/ieee80211_iface.c | 74 +--
3 files changed, 117 insertions(+), 62 deletions(-)
d809b662083c69de844d5fdcf33a8ef149c90b8e
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index ffb7985..1d6e87c 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -1954,8 +1954,6 @@ static inline int identical_mac_addr_all
{
return (type1 == IEEE80211_IF_TYPE_MNTR ||
type2 == IEEE80211_IF_TYPE_MNTR ||
- type1 == IEEE80211_IF_TYPE_MGMT ||
- type2 == IEEE80211_IF_TYPE_MGMT ||
(type1 == IEEE80211_IF_TYPE_AP &&
type2 == IEEE80211_IF_TYPE_WDS) ||
(type1 == IEEE80211_IF_TYPE_WDS &&
@@ -1990,6 +1988,20 @@ static int ieee80211_master_stop(struct
return 0;
}
+static int ieee80211_ap_open(struct net_device *dev)
+{
+ struct ieee80211_local *local = dev->priv;
+
+ if (local->ap_open_count == 0)
+ return -EOPNOTSUPP;
+ return 0;
+}
+
+static int ieee80211_ap_stop(struct net_device *dev)
+{
+ return 0;
+}
+
/* Check if running monitor interfaces should go to a "soft monitor" mode
* and switch them if necessary. */
static inline void ieee80211_start_soft_monitor(struct ieee80211_local *local)
@@ -2032,7 +2044,6 @@ static int ieee80211_open(struct net_dev
struct net_device *ndev = nsdata->dev;
if (ndev != dev && ndev != local->mdev &&
- ndev != local->apdev &&
netif_running(ndev) &&
memcmp(dev->dev_addr, ndev->dev_addr, ETH_ALEN) == 0 &&
!identical_mac_addr_allowed(sdata->type, nsdata->type)) {
@@ -2087,7 +2098,11 @@ static int ieee80211_open(struct net_dev
}
local->open_count++;
- if (sdata->type == IEEE80211_IF_TYPE_MNTR)
+ if (sdata->type == IEEE80211_IF_TYPE_AP) {
+ local->ap_open_count++;
+ if (local->ap_open_count == 1)
+ dev_open(local->apdev);
+ } else if (sdata->type == IEEE80211_IF_TYPE_MNTR)
local->monitors++;
netif_start_queue(dev);
@@ -2112,7 +2127,11 @@ static int ieee80211_stop(struct net_dev
netif_stop_queue(dev);
- if (sdata->type == IEEE80211_IF_TYPE_MNTR)
+ if (sdata->type == IEEE80211_IF_TYPE_AP) {
+ local->ap_open_count--;
+ if (local->ap_open_count == 0)
+ dev_close(local->apdev);
+ } else if (sdata->type == IEEE80211_IF_TYPE_MNTR)
local->monitors--;
local->open_count--;
@@ -2367,6 +2386,10 @@ ieee80211_rx_mgmt(struct net_device *dev
if (msg_type != ieee80211_msg_monitor)
dev = local->apdev;
+ if (!dev) {
+ dev_kfree_skb(skb);
+ return;
+ }
skb->dev = dev;
sdata = IEEE80211_DEV_TO_SUB_IF(dev);
@@ -3998,6 +4021,19 @@ void ieee80211_if_setup(struct net_devic
dev->destructor = ieee80211_if_free;
}
+void ieee80211_if_ap_setup(struct net_device *dev)
+{
+ ether_setup(dev);
+ dev->hard_start_xmit = ieee80211_mgmt_start_xmit;
+ dev->change_mtu = ieee80211_change_mtu_apdev;
+ dev->get_stats = ieee80211_get_stats;
+ dev->open = ieee80211_ap_open;
+ dev->stop = ieee80211_ap_stop;
+ dev->type = ARPHRD_IEEE80211_PRISM;
+ dev->hard_header_parse = header_parse_80211;
+ dev->tx_queue_len = 0;
+ dev->destructor = ieee80211_if_free;
+}
static void ieee80211_precalc_rates(struct ieee80211_hw *hw)
{
@@ -4018,7 +4054,7 @@ static void ieee80211_precalc_rates(stru
struct net_device *ieee80211_alloc_hw(size_t priv_data_len,
void (*setup)(struct net_device *))
{
- struct net_device *apdev, *mdev;
+ struct net_device *mdev;
struct ieee80211_local *local;
struct ieee80211_sub_if_data *sdata;
int alloc_size;
@@ -4038,17 +4074,11 @@ struct net_device *ieee80211_alloc_hw(si
* 0b84 *
* * hw_priv *
* 1664 *
- * * ap net_dev*
- * 17c0 *
- * * sub_if*
-* *
*/
alloc_size = sizeof(struct net_device) +
sizeof(struct ieee80211_sub_if_data) + 3 +
sizeof(struct ieee80211_local) + 3
[PATCH 3/3] d80211: fix is_ieee80211_device
Sending packets from management interface (wmasterXap) didn't work. This
patch fixes that problem; it's not nice but it will go away when the
interface between kernel and hostapd is changed to netlink (the packets will
be sent through master interface then).
Signed-off-by: Jiri Benc <[EMAIL PROTECTED]>
---
net/d80211/ieee80211.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
e0a6647c8a9371e00cfcb15452c6b577bc863f37
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index fc56450..701c38b 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -59,6 +59,8 @@ static int rate_control_initialize(struc
static u8 * ieee80211_get_bssid(struct ieee80211_hdr *hdr, size_t len);
+static int ieee80211_mgmt_start_xmit(struct sk_buff *skb,
+struct net_device *dev);
struct ieee80211_key_conf *
ieee80211_key_data2conf(struct ieee80211_local *local,
@@ -1097,7 +1099,8 @@ __ieee80211_tx_prepare(struct ieee80211_
static int inline is_ieee80211_device(struct net_device *dev)
{
return (dev->wireless_handlers ==
- (struct iw_handler_def *) &ieee80211_iw_handler_def);
+ (struct iw_handler_def *) &ieee80211_iw_handler_def) ||
+ (dev->hard_start_xmit == ieee80211_mgmt_start_xmit);
}
/* Device in tx->dev has a reference added; use dev_put(tx->dev) when
--
1.3.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
[PATCH 2/3] d80211: use alloc_netdev
Now when there are no interfaces allocated together anymore, let's use
alloc_netdev for allocation of interfaces. We save some code and also
the structures are really aligned finally.
Signed-off-by: Jiri Benc <[EMAIL PROTECTED]>
---
net/d80211/ieee80211.c | 43 --
net/d80211/ieee80211_i.h |6 +-
net/d80211/ieee80211_iface.c | 28 ++-
3 files changed, 31 insertions(+), 46 deletions(-)
df3a812091d971e8cec93d51b5a54b6d2ecfb400
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index 1d6e87c..fc56450 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -4057,43 +4057,40 @@ struct net_device *ieee80211_alloc_hw(si
struct net_device *mdev;
struct ieee80211_local *local;
struct ieee80211_sub_if_data *sdata;
- int alloc_size;
+ int priv_size;
- /* Ensure 32-bit alignment of our private data and hw private data.
-* Each net_device is followed by a sub_if_data which which is used
-* for wds/vlan information; it is aligned as well.
+ /* Ensure 32-byte alignment of our private data and hw private data.
+* Each net_device is followed by a sub_if_data which is used for
+* interface specific information.
*
* Sample memory map looks something like:
*
* *
* * net_dev *
- * 015c *
+* 0160 *
* * sub_if*
- * 017c *
+* 0180 *
* * local *
- * 0b84 *
+* 0b80 *
* * hw_priv *
* 1664 *
*/
-alloc_size = sizeof(struct net_device) +
-sizeof(struct ieee80211_sub_if_data) + 3 +
-sizeof(struct ieee80211_local) + 3 +
-priv_data_len + 3 +
- 4096;
-mdev = (struct net_device *) kzalloc(alloc_size, GFP_KERNEL);
+ priv_size = ((sizeof(struct ieee80211_sub_if_data) +
+ NETDEV_ALIGN_CONST) & ~NETDEV_ALIGN_CONST) +
+ ((sizeof(struct ieee80211_local) +
+ NETDEV_ALIGN_CONST) & ~NETDEV_ALIGN_CONST) +
+ priv_data_len;
+ mdev = alloc_netdev(priv_size, "wmaster%d", ether_setup);
if (mdev == NULL)
return NULL;
-mdev->priv = (struct net_device *)
- ((char *) mdev +
-((sizeof(struct net_device) + 3) & ~3) +
-((sizeof(struct ieee80211_sub_if_data) + 3) & ~3));
+ mdev->priv = (char *)netdev_priv(mdev) +
+((sizeof(struct ieee80211_sub_if_data) +
+ NETDEV_ALIGN_CONST) & ~NETDEV_ALIGN_CONST);
local = mdev->priv;
- local->hw_priv = (void *)
- ((char *) local + ((sizeof(struct ieee80211_local) + 3) & ~3));
-
- ether_setup(mdev);
- memcpy(mdev->name, "wmaster%d", 10);
+ local->hw_priv = (char *)local +
+((sizeof(struct ieee80211_local) +
+ NETDEV_ALIGN_CONST) & ~NETDEV_ALIGN_CONST);
local->dev_index = -1;
local->mdev = mdev;
@@ -4310,7 +4307,7 @@ void ieee80211_unregister_hw(struct net_
void ieee80211_free_hw(struct net_device *dev)
{
- kfree(dev);
+ free_netdev(dev);
}
diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h
index 15dcc95..5bf81ff 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
@@ -307,11 +307,7 @@ #define NUM_DEFAULT_KEYS 4
int channel_use_raw;
};
-#define IEEE80211_DEV_TO_SUB_IF(dev) ((struct ieee80211_sub_if_data *) \
- ((char *)(dev) + ((sizeof(struct net_device) + 3) & ~3)))
-#define IEEE80211_SUB_IF_TO_DEV(sub_if) ((struct net_device *) \
- ((char *)(sub_if) - ((sizeof(struct net_device) + 3) & ~3)))
-
+#define IEEE80211_DEV_TO_SUB_IF(dev) netdev_priv(dev)
struct ieee80211_local {
struct ieee80211_hw *hw;
diff --git a/net/d80211/ieee80211_iface.c b/net/d80211/ieee80211_iface.c
index 2738c94..3e3e5ca 100644
--- a/net/d80211/ieee80211_iface.c
+++ b/net/d80211/ieee80211_iface.c
@@ -31,16 +31,12 @@ int ieee80211_if_add(struct net_device *
struct net_device *ndev, *tmp_dev;
struct ieee80211_local *local = dev->priv;
struct ieee80211_sub_if_data *sdata = NULL, *sdata_parent;
- int alloc_size;
int ret;
int i;
ASSERT_RTNL();
- /* ensure 32-bit alignment of our private data and hw private data */
- alloc_size = sizeof(struct net_device) + 3 +
- sizeof(struct ieee80211_sub_if_data) + 3;
-
- ndev = *new_dev = (struct net_device *) kzalloc(alloc_size, GFP_KERNEL);
+ ndev = *new_dev = alloc_netdev(sizeof(struct ieee80211_sub_if_data),
+
Re: IP1000 gigabit nic driver
Pekka J Enberg wrote: > On Wed, 3 May 2006, Andrew Morton wrote: >> Please remember that to merge this we'll need a signed-off-by from the >> original developers. (That's not very gplish, but such is life). > > OK. Lets see if we can track one of them developers down. I see Craig > Rich's email (only email found in the original mail) is out of date so if > anyone knows how to reach him, please let me know. Thanks! I think/guess that IC Plus bought out Sundance so you'd need to contact someone at IC Plus. David Vrabel - 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: VJ Channel API - driver level (PATCH)
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of David S. Miller > Sent: Tuesday, May 02, 2006 11:48 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org > Subject: Re: VJ Channel API - driver level (PATCH) > > > I don't think we should be defining driver APIs when we > haven't even figured out how the core of it would even work yet. > > A key part of this is the netfilter bits, that will require > non-trivial flow identification, a hash will simply not be > enough, and it will not be allowed to not support the > netfilter bits properly since everyone will have netfilter > enabled in one way or another. Hi Dave, Do you have suggestions on potential hardware assists/offloads for netfilter? I suppose some of it can be worthwhile, although in general may be too complex to implement - especially above 1 Gig. I'd expect high end NIC ASICs to implement rx steering based upon some sort of hash (for load balancing), as well as explicit "1:1" steering between a sw channel and a hw channel. Both options for channel configuration are present in the driver interface. If netfilter assists can be done in hardware, I agree the driver interface will need to add support for these - otherwise, netfilter processing will stay above the driver. > - > To unsubscribe from this list: send the line "unsubscribe > netdev" in the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > - To unsubscribe from this list: send 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: Disabling "TCP Treason uncloaked"
On Wed, May 03, 2006 at 12:15:30PM +, Alexey Toptygin wrote:
>
> I'm curious, how would you do this without filling the disk? With a script
> that starts tcpdump to a ring in the background, waits for the offending
> log entry to appear and then kills tcpdump?
Well if you know the set of IPs that's likely to cause this you just
run tcpdump with an expression to filter out all traffic but those
IPs.
Sinec tcpdump only captures 100 bytes of each packet by default, it
should be manageable assuming that this problem occurs relatively
frequently.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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] ipg: removing more dead code
Hi David, On Wed, 3 May 2006, David Gómezz wrote: > I'll test it tomorrow ASAP. For now, here is another patch removing > more dead code. This code is never reached (NOTGRACE is not defined) > and the *fiber_detect functions are subsequently never used. No need to resend this one, but in future, please follow the proper patch format: http://www.zipworld.com.au/~akpm/linux/patches/stuff/tpp.txt Pekka - 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: IP1000 gigabit nic driver
On Wed, 3 May 2006, Andrew Morton wrote: > Please remember that to merge this we'll need a signed-off-by from the > original developers. (That's not very gplish, but such is life). OK. Lets see if we can track one of them developers down. I see Craig Rich's email (only email found in the original mail) is out of date so if anyone knows how to reach him, please let me know. Thanks! Pekka - 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: IP1000 gigabit nic driver
On Mon, 01 May 2006 12:31:40 +0300 Pekka Enberg <[EMAIL PROTECTED]> wrote: > [PATCH] IP1000 Gigabit Ethernet device driver > > This is a cleaned up fork of the IP1000A device driver: > > http://www.icplus.com.tw/driver-pp-IP1000A.html Please remember that to merge this we'll need a signed-off-by from the original developers. (That's not very gplish, but such is life). - 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: Disabling "TCP Treason uncloaked"
Hi Just Marc <[EMAIL PROTECTED]> wrote: That's good, but it may (and probably will) suppress many other messages which may be of more interest... That's the crux of the matter. There is no way we can satisfy everyone short of putting a knob on each individual printk. So the only solution is to do the filtering yourself in userspace through klogd/syslogd. It is the crux of the matter. This print is a purely informational one, absolutely harmless (unless I'm mistaken) and clogs kernel logs throughout the universe :) Seriously, other kernel prints are usually not so harmless and are generally more important to see. Let me put it another way, except this print, I have no other prints whatsoever on any of my machines and if there are prints, I usually do want to know about them, I learned to ignore this print over the years. I believe many people are in the same boat. That's my opinion, anyway. Thanks - 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: Disabling "TCP Treason uncloaked"
On Wed, May 03, 2006 at 01:47:31PM +0200, Ingo Oeser wrote:
>
> Already there: /proc/sys/net/core/{message_cost,message_burst}
>
> Just set burst to 0 and cost to a very big value to basically supppress
> all net_ratelimit()ed messages.
>
> Or did you think of sth. else?
No that'll do just fine.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: Disabling "TCP Treason uncloaked"
On Wed, 3 May 2006, Herbert Xu wrote: Can you take a tcpdump of the TCP sessions involving those IPs and then show me the sections that occur when those messages are triggered? I'm curious, how would you do this without filling the disk? With a script that starts tcpdump to a ring in the background, waits for the offending log entry to appear and then kills tcpdump? Alexey - 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: Disabling "TCP Treason uncloaked"
Hi On Wed, May 03, 2006 at 01:49:05PM +0100, Just Marc wrote: You're right, actually this box serves http/ftp file transfers only, it's a mirror with a large amount of downloads a day. That's interesting. The RX bug that I fixed earlier would usually manifest itself under exactly these conditions. Alas you're running a fixed kernel. I gave it another look, many of the prints are repeat prints for the same remote IPs, Can you take a tcpdump of the TCP sessions involving those IPs and then show me the sections that occur when those messages are triggered? OK, I'll try that. I agree, however, I think it's pretty good to allow an admin to toggle it off completely. Maybe that's all we need, really. The question is always what you want to be off and what to leave on. After all, you can turn off all printk's to the console through /proc. If you also tell klogd to ignore them then you won't see anything at all (unless you run dmesg). The problem is that it's really BAD to suppress all messages, there may be critical ones. In my opinion while the treason uncloaked message can help uncover bugs it is mostly redundant on a day to day usage for probably 99% of the scenarios. Marc - 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: Disabling "TCP Treason uncloaked"
Just Marc <[EMAIL PROTECTED]> wrote:
>
> That's good, but it may (and probably will) suppress many other messages
> which may be of more interest...
That's the crux of the matter. There is no way we can satisfy everyone
short of putting a knob on each individual printk.
So the only solution is to do the filtering yourself in userspace through
klogd/syslogd.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: Disabling "TCP Treason uncloaked"
Hi
Herbert Xu wrote:
BTW, this message is already under net_ratelimit so I don't see any
urgency in getting rid of it completely. If we're going down the
path of disabling it, we probably should go for something more global
rather than a sysctl that controls this one message.
Already there: /proc/sys/net/core/{message_cost,message_burst}
Just set burst to 0 and cost to a very big value to basically supppress
all net_ratelimit()ed messages.
Or did you think of sth. else?
That's good, but it may (and probably will) suppress many other messages
which may be of more interest...
Marc
-
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: net/d80211 and management interface (wmaster0ap)
On Tue, 2 May 2006 11:39:30 -0700, Jouni Malinen wrote: > It looks like one of your patches in wireless-dev.git broke management > interface. I'm not completely sure about how this was supposed to work, > but are the low-level drivers now expected to accept > IEEE80211_IF_TYPE_MGMT in add_interface handler or should ieee80211.c be > modified to accept wmaster0ap to be set UP without asking the low-level > driver? It shouldn't ask the driver. This was a part of the dropped patch for removing default management device. I will send a patch to address this particular issue later today. > In addition to this, it looked like sending packets from wmaster0ap did > not work. The packets were being dropped since originating device > (wmaster0ap) did not match in is_ieee80211_device(). This function > seemed to use wireless_handlers pointer for recognizing interfaces which > (like to comment says) is not that nice. wireless_handlers were not set > for apdev, so the patch below adds it to make TX work through > wmaster0ap. Oh, thanks for finding this. But we probably don't want wmaster0ap to have wireless_handlers set. I will try to rewrite is_ieee80211_device in some another way. Thanks, Jiri -- 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: Disabling "TCP Treason uncloaked"
On Wed, May 03, 2006 at 01:49:05PM +0100, Just Marc wrote:
>
> You're right, actually this box serves http/ftp file transfers only,
> it's a mirror with a large amount of downloads a day.
That's interesting. The RX bug that I fixed earlier would usually
manifest itself under exactly these conditions. Alas you're running
a fixed kernel.
> I gave it another look, many of the prints are repeat prints for the
> same remote IPs,
Can you take a tcpdump of the TCP sessions involving those IPs and
then show me the sections that occur when those messages are triggered?
> I agree, however, I think it's pretty good to allow an admin to toggle
> it off completely. Maybe that's all we need, really.
The question is always what you want to be off and what to leave on.
After all, you can turn off all printk's to the console through /proc.
If you also tell klogd to ignore them then you won't see anything at
all (unless you run dmesg).
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: Disabling "TCP Treason uncloaked"
Hi, Just Marc <[EMAIL PROTECTED]> wrote: We're now at 2.6.16.12 and it is still showing thousands of times a day on a busy web server, have all the bugs been discovered yet? There are no known bugs on the RX side in 2.6.16 that would cause this. The few busy web servers that I have access to do not see this message at all. So either your web server is somehow attracting a lot of buggy TCP stacks, or there could be a dodgy gateway in your path that is mucking with the TCP windows. You're right, actually this box serves http/ftp file transfers only, it's a mirror with a large amount of downloads a day. On a pure html/image web server that is just as busy, there are only a few of these messages, one or two a day. I suggest that you do a tcpdump to see what it looks like. It might turn out that we do still have a bug on our RX side. I gave it another look, many of the prints are repeat prints for the same remote IPs, BTW, this message is already under net_ratelimit so I don't see any urgency in getting rid of it completely. If we're going down the path of disabling it, we probably should go for something more global rather than a sysctl that controls this one message. I agree, however, I think it's pretty good to allow an admin to toggle it off completely. Maybe that's all we need, really. Thanks - 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: Disabling "TCP Treason uncloaked"
Herbert Xu wrote:
> BTW, this message is already under net_ratelimit so I don't see any
> urgency in getting rid of it completely. If we're going down the
> path of disabling it, we probably should go for something more global
> rather than a sysctl that controls this one message.
Already there: /proc/sys/net/core/{message_cost,message_burst}
Just set burst to 0 and cost to a very big value to basically supppress
all net_ratelimit()ed messages.
Or did you think of sth. else?
Regards
Ingo Oeser
-
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/9] natsemi: Add support for using MII port with no PHY
Mark Brown wrote: On Thu, Apr 27, 2006 at 05:54:58AM -0400, Jeff Garzik wrote: Provide a module option which configures the natsemi driver to use the external MII port on the chip but ignore any PHYs that may be attached to it. The link state will be left as it was when the driver started and can The proper way to do this is via the force_media boolean flag found in several net drivers. I've had a look at several of the net drivers that implement this option (e100, smc91x, starfire and the shared code in mii.c). Unless I'm misreading the code it looks like the effect of this option in those drivers is to disable autonegotiation but still configure the PHY when the NIC is configured. That is a subset of what the patch does and isn't sufficient for the hardware this patch targets: sometimes there may be a PHY visible on the MII bus but with a different configuration to the natsemi or there may be no PHY present at all. In this case the code in the natsemi driver that configures the PHY to match the configuration of the natsemi also needs to be disabled. It looks like I should implement a force_media option and redo this patch to use that. That's the sort of patch I'm looking for... 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: [PATCH] au1000_eth.c Power Management, driver registration and module support
Hello, yesterday I did a little mess with GIT... now the patch is complete. Sorry. :) I forgot also to say that it has been done against «linux-2.6.16-stable» branch. Ciao, Rodolfo -- GNU/Linux Solutions e-mail:[EMAIL PROTECTED] Linux Device Driver [EMAIL PROTECTED] Embedded Systems[EMAIL PROTECTED] UNIX programming phone: +39 349 2432127 signature.asc Description: Digital signature
Re: Disabling "TCP Treason uncloaked"
From: Andi Kleen <[EMAIL PROTECTED]> Date: Tue, 2 May 2006 18:02:43 +0200 On Tuesday 02 May 2006 18:19, Just Marc wrote: I thought that maybe it's time to either set TCP_DEBUG to 0 or alternatively allow an admin to toggle the printing of this message off/on? On a few busy web servers running usually latest versions of 2.6 I have this message displaying hundreds (if not more) times a day, You're talking to a lot of broken TCP clients then. Herbert Xu also fixed a bug that would cause that message to be emitted erroneously, 9 times out of 10 that is why people are seeing these messages. I think disabling that message is a non-starter, we want to see the message because as we've seen it can point to bugs on our end too. Correct, I noticed this was applied to 2.6.14, however, I am running 2.6.16 (and now 2.6.16.12) on all of the machines in question, I am seeing hundreds of these messages a day... Thanks - 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: Disabling "TCP Treason uncloaked"
Just Marc <[EMAIL PROTECTED]> wrote:
>
> We're now at 2.6.16.12 and it is still showing thousands of times a day
> on a busy web server, have all the bugs been discovered yet?
There are no known bugs on the RX side in 2.6.16 that would cause this.
The few busy web servers that I have access to do not see this message
at all.
So either your web server is somehow attracting a lot of buggy TCP stacks,
or there could be a dodgy gateway in your path that is mucking with the
TCP windows.
I suggest that you do a tcpdump to see what it looks like. It might turn
out that we do still have a bug on our RX side.
BTW, this message is already under net_ratelimit so I don't see any
urgency in getting rid of it completely. If we're going down the
path of disabling it, we probably should go for something more global
rather than a sysctl that controls this one message.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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
