Re: [PATCH 1/6] d80211: change the cookie to be opaque
On Thu, 2006-11-02 at 23:15 -0500, John W. Linville wrote: 403 Forbidden (shouldn't that be Verboten? :-) Nah, that's ok, that particular Apache instance is running in London, UK :) Fixed, sorry about that, I don't usually allow directory listing in that hierarchy and forgot to enable it (so you could have gotten d80211-reduce-mdev.patch by appending it to that URL :) johannes - 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/6] d80211: change the cookie to be opaque
On Thu, 2006-11-02 at 21:28 -0500, Michael Wu wrote: That's because TX might fail for reasons other than not getting an ACK. I can't say I've actually seen this happen, so it might just be something left over from tulip that doesn't need to be there now. (or perhaps it only happens when there's something really bad going on) However, what's so bad about letting drivers update some statistics if it is possible? If you remove ieee80211_dev_stats, please provide some other way for drivers to access struct net_device_stats. Well, you were only changing the master netdev's stats, which isn't really useful because you want to change the device that transmitted the frame. But you cannot, because you don't have access to it. In general, the stack should be doing this, so if some other tx errors are possible maybe we should add a flag to the tx status. johannes - 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: New stuff in wireless-dev, wireless developers please pull...
On Fri, 2006-11-03 at 01:42 -0500, Michael Wu wrote: This is with cfg80211 turned off. wext-old.c shouldn't be compiled then. Must be some Makefile bug, I'll look into it. johannes - 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: New stuff in wireless-dev, wireless developers please pull...
On Thu, 2006-11-02 at 23:30 -0500, John W. Linville wrote: I've also added a 'pending' branch, with similar policies to the 'pending' branch in wireless-2.6 (i.e it means I've got the patch, but I'm waiting on some feedback or changes, etc). Note that the d80211: change the cookie to be opaque as committed is actually slightly buggy as I pointed out in a follow-up mail, the quilt dir that's up on my homepage (which is now accessible too...) contains the fixed version. One big addition is the cfg80211/nl80211 stuff from Johannes. I'm not quite confident that the Kconfig stuff is right, but the code is there. Nice :) johannes - 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 6/6] IPv6: Fix infinite loop if no matching IPv6 tunnel found
YOSHIFUJI Hideaki wrote: In article [EMAIL PROTECTED] (at Thu, 02 Nov 2006 15:16:23 +0200), Ville Nuorvala [EMAIL PROTECTED] says: On 11/02/06 14:59, YOSHIFUJI Hideaki wrote: In article [EMAIL PROTECTED] (at Thu, 02 Nov 2006 13:39:19 +0200), Ville Nuorvala [EMAIL PROTECTED] says: read_unlock(ip6ip6_lock); - return 1; - + icmpv6_send(skb, ICMPV6_DEST_UNREACH, + ICMPV6_ADDR_UNREACH, 0, skb-dev); discard: I'd argue this. We probably should not send back any ICMPv6 packets to the original sender in this case to avoid DoS. Sorry, I don't follow you. I don't see the DoS scenario here (after we apply the patch, that is ;-). Well, leaving aside whether sending icmpv6 is good thing (*), the code for sending icmpv6 was moved from ip6_tunnel.c to tunnel6.c by commit-id 50fba2aa7cefa6b0e1768cb350c9e69042320c03 by Herbert. The ip6_tunnel.c change that Herbert made does not seem consistent with ipip.c change. To fix your issue the appropriate change is just fall through to discard section, as we're doing for ipip.c. Ah, I hadn't noticed Herbert's patch. It actually appears to fix the problem I was trying to fix here. AFAIK Tero experienced the infinite loop on a 2.6.16 kernel. Regards, Ville - 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/6] d80211: change the cookie to be opaque
On Fri, 2006-11-03 at 01:46 +0100, Johannes Berg wrote:
d80211-reduce-mdev.patch
d80211-ethtool.patch
d80211-cookie.patch
G, whitespace damaged. I swear I'm going to submit a s/ {8}/\t/
patch some of these days. wiggle should handle that just fine, and
personally, I have reached a point where I'm far more annoyed by the
damaged whitespace all over than I would be if a patch failed to apply
(which actually happens all the time, so it's sort of a regular thing)
In the meantime, I've fixed the damage.
johannes
-
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: [take22 0/4] kevent: Generic event handling mechanism.
Hi! returns, which thread are you referring to? Nicholas Miell, in The Proposed Linux kevent API thread, seems to think that there are no advantages over kqueue to justify the incompatibility, an argument you made no effort to refute. I've also read the Kevent wiki at linux-net.osdl.org, but it too is lacking in any direct comparisons (even theoretical, let alone benchmarks) of the flexibility, performance, etc. between the two. I'm not arguing that you've done a bad design, I'm asking you to brag about the things you improved on vs. kqueue. Your emphasis on unifying all the different event types into one interface is really cool, fill me in on why that can't be effectively done with the kqueue compatability and I also will advocate for kevent inclusion. kqueue just can not be used as is in Linux (_maybe_ *bsd has different types, not those which I found in /usr/include in my FC5 and Debian distro). It will not work on x86_64 for example. Some kind of a pointer or unsigned long in structures which are transferred between kernelspace and userspace is so much questionable, than it is much better even do not see there... (if I would not have so political correctness, I would describe it in a much different words actually). So, kqueue API and structures can not be usd in Linux. Not sure what you are smoking, but there's unsigned long in *bsd version, lets rewrite it from scratch sounds like very bad idea. What about fixing that one bit you don't like? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [take22 0/4] kevent: Generic event handling mechanism.
From: Pavel Machek [EMAIL PROTECTED] Date: Fri, 3 Nov 2006 09:57:12 +0100 Not sure what you are smoking, but there's unsigned long in *bsd version, lets rewrite it from scratch sounds like very bad idea. What about fixing that one bit you don't like? I disagree, it's more like since we have to be structure incompatible anyways, let's design something superior if we can. - 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: [take22 0/4] kevent: Generic event handling mechanism.
On Fri, Nov 03, 2006 at 09:57:12AM +0100, Pavel Machek ([EMAIL PROTECTED]) wrote: So, kqueue API and structures can not be usd in Linux. Not sure what you are smoking, but there's unsigned long in *bsd version, lets rewrite it from scratch sounds like very bad idea. What about fixing that one bit you don't like? It is not about what I dislike, but about what is broken or not. Putting u64 instead of a long or some kind of that _is_ incompatible already, so why should we even use it? And, btw, what we are talking about? Is it about the whole kevent compared to kqueue in kernelspace, or just about what structure is being transferred between kernelspace and userspace? I'm sure, it was some kind of a joke to 'not rewrite *bsd from scratch and use kqueue in Linux kernel as is'. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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: [take22 0/4] kevent: Generic event handling mechanism.
On Fri, Nov 03, 2006 at 10:42:04AM +0800, zhou drangon ([EMAIL PROTECTED]) wrote: As for the VFS system, when we introduce the AIO machinism, we add aio_read, aio_write, etc... to file ops, and then we make the read, write op to call aio_read, aio_write, so that we only remain one implement in kernel. Can we do event machinism the same way? when kevent is robust enough, can we implement epoll/select/io_submit etc... base on kevent ?? In this way, we can simplified the kernel, and epoll can gain improvement from kevent. There is AIO implementaion on top of kevent, although it was confirmed that it has a good design, except minor API layering changes, it was postponed for a while. -- 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: [PATCH] Update SNMP basic for full IP address NAT
zze-Ganesh KERDONCUFF G ext RD-MAPS-REN wrote: The algorithm now applies NAT to the complete IP address (and not only the first byte) It also recomputes the UDP checksum accordingly. I'm not too familiar with SNMP NAT, please send this to [EMAIL PROTECTED] so other netfilter developers get a chance to look at it. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] IPv6: Fix infinite loop if no matching IPv6 tunnel found
Ville Nuorvala wrote: YOSHIFUJI Hideaki wrote: In article [EMAIL PROTECTED] (at Thu, 02 Nov 2006 15:16:23 +0200), Ville Nuorvala [EMAIL PROTECTED] says: On 11/02/06 14:59, YOSHIFUJI Hideaki wrote: In article [EMAIL PROTECTED] (at Thu, 02 Nov 2006 13:39:19 +0200), Ville Nuorvala [EMAIL PROTECTED] says: read_unlock(ip6ip6_lock); - return 1; - + icmpv6_send(skb, ICMPV6_DEST_UNREACH, + ICMPV6_ADDR_UNREACH, 0, skb-dev); discard: I'd argue this. We probably should not send back any ICMPv6 packets to the original sender in this case to avoid DoS. Sorry, I don't follow you. I don't see the DoS scenario here (after we apply the patch, that is ;-). Well, leaving aside whether sending icmpv6 is good thing (*), the code for sending icmpv6 was moved from ip6_tunnel.c to tunnel6.c by commit-id 50fba2aa7cefa6b0e1768cb350c9e69042320c03 by Herbert. The ip6_tunnel.c change that Herbert made does not seem consistent with ipip.c change. To fix your issue the appropriate change is just fall through to discard section, as we're doing for ipip.c. Ah, I hadn't noticed Herbert's patch. It actually appears to fix the problem I was trying to fix here. AFAIK Tero experienced the infinite loop on a 2.6.16 kernel. Correct, it was a 2.6.16.29 kernel patched with MIPL 2.0.2. The problem was obviously not whether an ICMP error was sent or not but that a wrong return value was used. However, if that's then already fixed in newer kernels where MIPL is included in the source tree, we all can be happy again. :) -- Tero - 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: [KJ] [patch] net/tipc: sprintf/strcpy conversion
* Alexey Dobriyan | 2006-11-03 03:09:05 [+0300]: On Wed, Nov 01, 2006 at 03:06:24PM +0100, Florian Westphal wrote: convert sprintf(a,b) to strcpy(a,b). Make tipc_bclink_name[] const. Ahhh, I missed the start of threads. Patch is useless because it changes one unbounded string function into another unbounded string function. The discussion in this thread is really back-breaking! 1. To make tipc_bclink_name const there is absolutly no objection 2. Replace sprintf with strcpy a) First of all: If you _copy_ a string then use also strCPY() Thats a question of good style! b) If the compiler is smart enough, he realize that you want to copy a string and replace the sprintf call with a pushl %ebx callstrcpy Surprise - Surprise! Assumed you use gcc with -Os or -O2! Don't know how icc handle this case. If you compile without optimization you save at least a repz movsb %ds:(%esi),%es:(%edi) instruction. c) Last but not least I read all the time this patch doesn't introduce bounds-checking. This isn't a argument because the author is aware of the destination length of the buffer. BTW: grep for (sprintf|strcpy) in /usr/src/linux and be surprised how unsecure the kernel is (thats ironical). This patch is 100% OK! HGN - 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: pktgen patch available for perusal.
Ben Greear writes: I'd be thrilled to have the receive logic go into pktgen, even if it was #if 0 with a comment showing how to patch dev.c to get it working. It would make my out-of-tree patch smaller and should help others who are doing research and driver development... Just an idea... RX part is pretty separate from TX. How about if we keep the this code in a small seprate optional module? It can developed into some general RX probe. Cheers. --ro - 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: New stuff in wireless-dev, wireless developers please pull...
On Fri, 2006-11-03 at 10:06 +0100, Johannes Berg wrote: It doesn't seem to compile on my system: net/built-in.o: In function `iw_send_thrspy_event': wext-old.c:(.text+0x67672): undefined reference to `wireless_send_event' Uh, common is missing. Adjust net/wireless/Makefile like this: Alright, I've uploaded a proper patch for this and fixed up all my other patches to apply against the current wireless-dev. johannes - 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] add ndisc_netdev_notifier unregister
If inet6_init() fails later than ndisc_init() call, or IPv6 module is
unloaded, ndisc_netdev_notifier call remains in the list and will follows in
oops later.
Signed-off-by: Dmitry Mishin [EMAIL PROTECTED]
---
ndisc.c |1 +
1 file changed, 1 insertion(+)
---
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 41a8a5f..73eb8c3 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1742,6 +1742,7 @@ #endif
void ndisc_cleanup(void)
{
+ unregister_netdevice_notifier(ndisc_netdev_notifier);
#ifdef CONFIG_SYSCTL
neigh_sysctl_unregister(nd_tbl.parms);
#endif
-
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-2.6-git] prism54: WPA/RSN support for fullmac cards
On Tue, 2006-10-31 at 11:05 -0500, Dan Williams wrote: On Mon, 2006-10-30 at 15:17 -0500, Luis R. Rodriguez wrote: On 10/29/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: This patch completes WPA/RSN with TKIP support for all fullmac prism54 cards. I removed all parts which are not relevant for wpa_supplicant (managed mode). This is great effort and thanks for it! My only concern with the patch is breaking compatiblity with 2.4 but then again I'm tired of having to keep this compat work up too and soon, after d80211 full force push it may not be possible. So I ACK it. I'd like to test it a bit first with my fullmac card before it gets committed/added... But it's great to get some movement on this card/driver! So my prism54 fullmac card appears to be broken, since it refuses to associate with anything at all, even unencrypted access points. It doesn't throw any errors at all, and it appears to be operating correctly other than not associating. Is there any way to get more information out of the firmware about what it's doing? Dan Dan Luis - 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 - 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-2.6-git] prism54: WPA/RSN support for fullmac cards
On 11/3/06, Dan Williams [EMAIL PROTECTED] wrote: On Tue, 2006-10-31 at 11:05 -0500, Dan Williams wrote: On Mon, 2006-10-30 at 15:17 -0500, Luis R. Rodriguez wrote: On 10/29/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: This patch completes WPA/RSN with TKIP support for all fullmac prism54 cards. I removed all parts which are not relevant for wpa_supplicant (managed mode). This is great effort and thanks for it! My only concern with the patch is breaking compatiblity with 2.4 but then again I'm tired of having to keep this compat work up too and soon, after d80211 full force push it may not be possible. So I ACK it. I'd like to test it a bit first with my fullmac card before it gets committed/added... But it's great to get some movement on this card/driver! So my prism54 fullmac card appears to be broken, since it refuses to associate with anything at all, even unencrypted access points. It doesn't throw any errors at all, and it appears to be operating correctly other than not associating. chunkeey, I figured your patch was well tested as you had it sitting there for a while I gotta find a fullmac working card (most of them broke while debugging) to debug. Is there any way to get more information out of the firmware about what it's doing? The driver supports prism54_get_oid and prism54_set_u32. The list of OIDs available are on isl_oid.h on oid_num_t enum. Just an FYI you if you need to access the *EX OIDs you just need to be in extended mode. Also for WPA you need to be in extended mode. To say the least last the driver was pretty unstable in extended mode last I used worked on it. Dan do you get any funky mgt timeouts on your ring buffer? Anything useful there? Luis - 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: pktgen patch available for perusal.
Robert Olsson wrote: Ben Greear writes: I'd be thrilled to have the receive logic go into pktgen, even if it was #if 0 with a comment showing how to patch dev.c to get it working. It would make my out-of-tree patch smaller and should help others who are doing research and driver development... Just an idea... RX part is pretty separate from TX. How about if we keep the this code in a small seprate optional module? It can developed into some general RX probe. It requires a hook in dev.c, or at least that is the only way I can think to implement it. I don't think that hook is going to be allowed into the kernel, so the best I was hoping for was to have the code in pktgen with #if 0 and let users patch their kernel to add the hook... Ben Cheers. --ro - 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 -- 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
[PATCH 2.6.19-rc4 2/3] ehea: Removed redundant define
Removed define H_CB_ALIGNMENT which is already defined in include/asm-powerpc/hvcall.h Signed-off-by: Thomas Klein [EMAIL PROTECTED] --- diff -Nurp git.netdev-2.6.base/drivers/net/ehea/ehea.h git.netdev-2.6/drivers/net/ehea/ehea.h --- git.netdev-2.6.base/drivers/net/ehea/ehea.h 2006-11-03 14:19:51.0 +0100 +++ git.netdev-2.6/drivers/net/ehea/ehea.h 2006-11-03 14:37:30.0 +0100 @@ -39,7 +39,7 @@ #include asm/io.h #define DRV_NAME ehea -#define DRV_VERSIONEHEA_0034 +#define DRV_VERSIONEHEA_0043 #define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \ | NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR) @@ -105,9 +105,6 @@ #define EHEA_BCMC_VLANID_ALL 0x01 #define EHEA_BCMC_VLANID_SINGLE0x00 -/* Use this define to kmallocate pHYP control blocks */ -#define H_CB_ALIGNMENT 4096 - #define EHEA_CACHE_LINE 128 /* Memory Regions */ - 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.6.19-rc4 1/3] ehea: Nullpointer dereferencation fix
Fix: Must check for nullpointer before dereferencing it - not afterwards.
Signed-off-by: Thomas Klein [EMAIL PROTECTED]
---
diff -Nurp git.netdev-2.6.base/drivers/net/ehea/ehea_qmr.c
git.netdev-2.6/drivers/net/ehea/ehea_qmr.c
--- git.netdev-2.6.base/drivers/net/ehea/ehea_qmr.c 2006-11-03
14:19:51.0 +0100
+++ git.netdev-2.6/drivers/net/ehea/ehea_qmr.c 2006-11-03 14:27:53.0
+0100
@@ -209,11 +209,11 @@ int ehea_destroy_cq(struct ehea_cq *cq)
{
u64 adapter_handle, hret;
- adapter_handle = cq-adapter-handle;
-
if (!cq)
return 0;
+ adapter_handle = cq-adapter-handle;
+
/* deregister all previous registered pages */
hret = ehea_h_free_resource(adapter_handle, cq-fw_handle);
if (hret != H_SUCCESS) {
-
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.6.19-rc4 3/3] ehea: 64K page support fix
This patch fixes 64k page support by using PAGE_MASK and appropriate pagesize
defines in several places.
Signed-off-by: Thomas Klein [EMAIL PROTECTED]
drivers/net/ehea/ehea_ethtool.c |2 +-
drivers/net/ehea/ehea_main.c| 26 +-
drivers/net/ehea/ehea_phyp.c|2 +-
drivers/net/ehea/ehea_phyp.h|6 --
drivers/net/ehea/ehea_qmr.c | 13 +++--
5 files changed, 26 insertions(+), 23 deletions(-)
diff -Nurp git.linux-2.6.base/drivers/net/ehea/ehea_ethtool.c
git.linux-2.6/drivers/net/ehea/ehea_ethtool.c
--- git.linux-2.6.base/drivers/net/ehea/ehea_ethtool.c 2006-11-03
16:41:36.0 +0100
+++ git.linux-2.6/drivers/net/ehea/ehea_ethtool.c 2006-11-03
12:43:16.0 +0100
@@ -238,7 +238,7 @@ static void ehea_get_ethtool_stats(struc
data[i++] = port-port_res[0].swqe_refill_th;
data[i++] = port-resets;
- cb6 = kzalloc(H_CB_ALIGNMENT, GFP_KERNEL);
+ cb6 = kzalloc(PAGE_SIZE, GFP_KERNEL);
if (!cb6) {
ehea_error(no mem for cb6);
return;
diff -Nurp git.linux-2.6.base/drivers/net/ehea/ehea_main.c
git.linux-2.6/drivers/net/ehea/ehea_main.c
--- git.linux-2.6.base/drivers/net/ehea/ehea_main.c 2006-11-03
16:41:36.0 +0100
+++ git.linux-2.6/drivers/net/ehea/ehea_main.c 2006-11-03 12:43:16.0
+0100
@@ -92,7 +92,7 @@ static struct net_device_stats *ehea_get
memset(stats, 0, sizeof(*stats));
- cb2 = kzalloc(H_CB_ALIGNMENT, GFP_KERNEL);
+ cb2 = kzalloc(PAGE_SIZE, GFP_KERNEL);
if (!cb2) {
ehea_error(no mem for cb2);
goto out;
@@ -586,8 +586,8 @@ int ehea_sense_port_attr(struct ehea_por
u64 hret;
struct hcp_ehea_port_cb0 *cb0;
- cb0 = kzalloc(H_CB_ALIGNMENT, GFP_ATOMIC); /* May be called via */
- if (!cb0) { /* ehea_neq_tasklet() */
+ cb0 = kzalloc(PAGE_SIZE, GFP_ATOMIC); /* May be called via */
+ if (!cb0) { /* ehea_neq_tasklet() */
ehea_error(no mem for cb0);
ret = -ENOMEM;
goto out;
@@ -670,7 +670,7 @@ int ehea_set_portspeed(struct ehea_port
u64 hret;
int ret = 0;
- cb4 = kzalloc(H_CB_ALIGNMENT, GFP_KERNEL);
+ cb4 = kzalloc(PAGE_SIZE, GFP_KERNEL);
if (!cb4) {
ehea_error(no mem for cb4);
ret = -ENOMEM;
@@ -985,7 +985,7 @@ static int ehea_configure_port(struct eh
struct hcp_ehea_port_cb0 *cb0;
ret = -ENOMEM;
- cb0 = kzalloc(H_CB_ALIGNMENT, GFP_KERNEL);
+ cb0 = kzalloc(PAGE_SIZE, GFP_KERNEL);
if (!cb0)
goto out;
@@ -1443,7 +1443,7 @@ static int ehea_set_mac_addr(struct net_
goto out;
}
- cb0 = kzalloc(H_CB_ALIGNMENT, GFP_KERNEL);
+ cb0 = kzalloc(PAGE_SIZE, GFP_KERNEL);
if (!cb0) {
ehea_error(no mem for cb0);
ret = -ENOMEM;
@@ -1501,7 +1501,7 @@ static void ehea_promiscuous(struct net_
if ((enable port-promisc) || (!enable !port-promisc))
return;
- cb7 = kzalloc(H_CB_ALIGNMENT, GFP_ATOMIC);
+ cb7 = kzalloc(PAGE_SIZE, GFP_ATOMIC);
if (!cb7) {
ehea_error(no mem for cb7);
goto out;
@@ -1870,7 +1870,7 @@ static void ehea_vlan_rx_register(struct
port-vgrp = grp;
- cb1 = kzalloc(H_CB_ALIGNMENT, GFP_KERNEL);
+ cb1 = kzalloc(PAGE_SIZE, GFP_KERNEL);
if (!cb1) {
ehea_error(no mem for cb1);
goto out;
@@ -1899,7 +1899,7 @@ static void ehea_vlan_rx_add_vid(struct
int index;
u64 hret;
- cb1 = kzalloc(H_CB_ALIGNMENT, GFP_KERNEL);
+ cb1 = kzalloc(PAGE_SIZE, GFP_KERNEL);
if (!cb1) {
ehea_error(no mem for cb1);
goto out;
@@ -1935,7 +1935,7 @@ static void ehea_vlan_rx_kill_vid(struct
if (port-vgrp)
port-vgrp-vlan_devices[vid] = NULL;
- cb1 = kzalloc(H_CB_ALIGNMENT, GFP_KERNEL);
+ cb1 = kzalloc(PAGE_SIZE, GFP_KERNEL);
if (!cb1) {
ehea_error(no mem for cb1);
goto out;
@@ -1968,7 +1968,7 @@ int ehea_activate_qp(struct ehea_adapter
u64 dummy64 = 0;
struct hcp_modify_qp_cb0* cb0;
- cb0 = kzalloc(H_CB_ALIGNMENT, GFP_KERNEL);
+ cb0 = kzalloc(PAGE_SIZE, GFP_KERNEL);
if (!cb0) {
ret = -ENOMEM;
goto out;
@@ -2269,7 +2269,7 @@ int ehea_sense_adapter_attr(struct ehea_
u64 hret;
int ret;
- cb = kzalloc(H_CB_ALIGNMENT, GFP_KERNEL);
+ cb = kzalloc(PAGE_SIZE, GFP_KERNEL);
if (!cb) {
ret = -ENOMEM;
goto out;
@@ -2340,7 +2340,7 @@ static int ehea_setup_single_port(struct
goto out;
/* Enable Jumbo frames */
- cb4 =
Re: [PATCH] bcm43xx: Drain TX status before starting IRQs
On Thu, Nov 02, 2006 at 09:45:46AM +0100, Johannes Berg wrote: On Wed, 2006-11-01 at 23:46 -0600, Larry Finger wrote: Has anyone used this patch, particularly with WPA encryption? When I try it, wpa_supplicant immediately uses 90+% of the cpu and never actually authenticates with my AP. I wonder if it is something with my system. What does wpa_supplicant do here? Have you looked at the debug log? Is it in some kind of busy loop doing something? Unless wpa supplicant is stupid [1] this cannot cause it any problems. johannes [1] by that, I mean sending out frames, turning off and on the interface, and then hoping to get a transmit status for frames sent before off/on cycle. wpa_supplicant does not receive or query TX status (at least yet; in the user space MLME case this is likely to change at some point). -- 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: [airo.c bug] Couldn't allocate RX FID / Max tries exceeded when issueing command
You might find this thread useful if it is just a case of messed up firmware: http://sourceforge.net/mailarchive/message.php?msg_id=2970511 The gist of it is that sometimes DOS utilities work when all else fails. ben --- Ivan Matveich [EMAIL PROTECTED] wrote: On 11/2/06, Dan Williams [EMAIL PROTECTED] wrote: Do you know which kernel version that patch first appeared in? It was committed on 1 Dec 2005, and 2.6.15 was released on 3 Jan 2006. That would be a great idea, let us know what the results are, especially if you cna figure out which firmware version you have, or if the card itself is really just dead. No luck with freebsd: error resetting card. I'll try my luck with Cisco's Windows utility---probably tomorrow---but I'd now wager that my card has simply croaked. (I've even taken it out and re-seated it in its slot, just in case that helped.) In any case, thanks for the help. - 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-2.6-git] prism54: WPA/RSN support for fullmac cards
On 11/3/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Am Freitag, 3. November 2006 17:06 schrieben Sie: On 11/3/06, Dan Williams [EMAIL PROTECTED] wrote: On Tue, 2006-10-31 at 11:05 -0500, Dan Williams wrote: On Mon, 2006-10-30 at 15:17 -0500, Luis R. Rodriguez wrote: On 10/29/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: This patch completes WPA/RSN with TKIP support for all fullmac prism54 cards. I removed all parts which are not relevant for wpa_supplicant (managed mode). This is great effort and thanks for it! My only concern with the patch is breaking compatiblity with 2.4 but then again I'm tired of having to keep this compat work up too and soon, after d80211 full force push it may not be possible. So I ACK it. I'd like to test it a bit first with my fullmac card before it gets committed/added... But it's great to get some movement on this card/driver! So my prism54 fullmac card appears to be broken, since it refuses to associate with anything at all, even unencrypted access points. It doesn't throw any errors at all, and it appears to be operating correctly other than not associating. chunkeey, I figured your patch was well tested as you had it sitting there for a while I gotta find a fullmac working card (most of them broke while debugging) to debug. well, it was already tested by: Maxi, Dan S., Gabriel, C and me. The best configuration is: WPA2 with TKIP! Is there any way to get more information out of the firmware about what it's doing? The driver supports prism54_get_oid and prism54_set_u32. The list of OIDs available are on isl_oid.h on oid_num_t enum. Just an FYI you if you need to access the *EX OIDs you just need to be in extended mode. Also for WPA you need to be in extended mode. To say the least last the driver was pretty unstable in extended mode last I used worked on it. Dan do you get any funky mgt timeouts on your ring buffer? Anything useful there? Luis yes, especially mgt_commit_list caused alot headaches, until I removed DOT11_OID_PSM from the cache list. Now, I can hammer it with ping -f for hours. nice, perhaps that's been the culprit all along... going to dig to see if I find a fullmac prism card. Will like to get this merged in. Luis - 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 0/6] rework d80211 cookie pointer
On Thursday 02 November 2006 17:38, Johannes Berg wrote: I'm sorry I didn't manage to update these drivers. As for out-of-tree drivers, I obviously haven't updated them either. It *shouldn't* be too hard as the net_dev shouldn't be used in many places. So uh, what am I going to prefix all my printk messages with now that I can't access dev-name? It seems like the other d80211 drivers have a habit of prefixing their messages with the driver name (wrong thing to do, IMHO), which is different from pretty much all other network drivers. -Michael Wu pgpdUJlLkwozo.pgp Description: PGP signature
Re: [PATCH 0/6] rework d80211 cookie pointer
Michael Wu wrote: So uh, what am I going to prefix all my printk messages with now that I can't access dev-name? It seems like the other d80211 drivers have a habit of prefixing their messages with the driver name (wrong thing to do, IMHO), which is different from pretty much all other network drivers. Yeah, I thought about that and added that function to get the wiphy index. cfg80211 makes the wiphy index an actual identifier that you can use to enumerate all devices it has attached etc, so that makes sense. and d80211 also puts it into sysfs. Is that good enough? johannes - 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] d80211: use pfifo_qdisc_ops rather thand80211-specificqdisc
I'm not sure why we don't use the master device for packet capture - I can't think of any good reason for requiring a separate device. I would think the master device is the perfect place to do packet capture, and raw packet transmission. Simon -Original Message- From: Johannes Berg [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 2:57 PM To: Stephen Hemminger Cc: Simon Barber; Christoph Hellwig; James Ketrenos; John W. Linville; Jeff Garzik; Patrick McHardy; David Kimdon; netdev@vger.kernel.org Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather thand80211-specificqdisc On Thu, 2006-11-02 at 14:34 -0800, Stephen Hemminger wrote: It makes 802.11 packet capture easier as well. Please don't invent yet another network access object for the master device. Oh, but the master device doesn't get any packets you could capture. For that, you need to add a monitor interface. johannes - 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] d80211: use pfifo_qdisc_ops rather thand80211-specificqdisc
I should elaborate - if 802.11 is made into a real protocol - then raw packet capture works correctly on the master device. (raw sockets opened on the device see all frames before they are passed to the protocol). This is the right way to go. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Barber Sent: Friday, November 03, 2006 11:24 AM To: Johannes Berg; Stephen Hemminger Cc: Christoph Hellwig; James Ketrenos; John W. Linville; Jeff Garzik; Patrick McHardy; David Kimdon; netdev@vger.kernel.org Subject: RE: [patch] d80211: use pfifo_qdisc_ops rather thand80211-specificqdisc I'm not sure why we don't use the master device for packet capture - I can't think of any good reason for requiring a separate device. I would think the master device is the perfect place to do packet capture, and raw packet transmission. Simon -Original Message- From: Johannes Berg [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 2:57 PM To: Stephen Hemminger Cc: Simon Barber; Christoph Hellwig; James Ketrenos; John W. Linville; Jeff Garzik; Patrick McHardy; David Kimdon; netdev@vger.kernel.org Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather thand80211-specificqdisc On Thu, 2006-11-02 at 14:34 -0800, Stephen Hemminger wrote: It makes 802.11 packet capture easier as well. Please don't invent yet another network access object for the master device. Oh, but the master device doesn't get any packets you could capture. For that, you need to add a monitor interface. johannes - 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: [patch] d80211: use pfifo_qdisc_ops rather thand80211-specificqdisc
On Fri, Nov 03, 2006 at 11:29:33AM -0800, Simon Barber wrote: I should elaborate - if 802.11 is made into a real protocol - then raw packet capture works correctly on the master device. (raw sockets opened on the device see all frames before they are passed to the protocol). This is the right way to go. There is some merit to this idea. Then we could attach IBSS, WDS, STA, or AP sub-interfaces (with or without ethernet encapsulation) in a manner similar to how VLAN sub-interfaces are attached to ethernet devices today. Of course, I seem to remember ranting against that model a few months ago. I'll just wave my hands and call it pragmatism... :-) John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pktgen patch available for perusal.
Ben Greear writes: It requires a hook in dev.c, or at least that is the only way I can think to implement it. Well the hook be placed along the packet path even in drivers. In tulip I didn't even take packet of the ring in some experiments. And there plenty of existing hooks already i.e PRE_ROUTE? I don't think that hook is going to be allowed into the kernel, so the best I was hoping for was to have the code in pktgen with #if 0 and let users patch their kernel to add the hook... Right so what I was trying to say was rather having #if 0 and dead code in pktgen it could be kept separate. Cheers. --ro - 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: pktgen patch available for perusal.
Robert Olsson wrote:
Ben Greear writes:
It requires a hook in dev.c, or at least that is the only way I can
think to implement it.
Well the hook be placed along the packet path even in drivers. In tulip I didn't
even take packet of the ring in some experiments.
And there plenty of existing hooks already i.e PRE_ROUTE?
For my particular application the hook needs to be right
after the bridge hook. My dev.c hook looks like this:
#if defined(CONFIG_NET_PKTGEN) || defined(CONFIG_NET_PKTGEN_MODULE)
#include pktgen.h
#warning Compiling dev.c for pktgen.;
int (*handle_pktgen_hook)(struct sk_buff *skb) = NULL;
EXPORT_SYMBOL(handle_pktgen_hook);
static __inline__ int handle_pktgen_rcv(struct sk_buff* skb) {
if (handle_pktgen_hook) {
return handle_pktgen_hook(skb);
}
return -1;
}
#endif
.
#if defined(CONFIG_NET_PKTGEN) || defined(CONFIG_NET_PKTGEN_MODULE)
if ((skb-dev-pkt_dev)
(handle_pktgen_rcv(skb) = 0)) {
/* Pktgen may consume the packet, no need to send
* to further protocols.
*/
goto out;
}
#endif
If the rx-hook logic is already in pktgen module, and it's symbol
exported, perhaps a second hook module could be written that
would just be the bridge between a driver or a PRE-ROUTE hook
and pktgen? The hook module would probably not be much larger
than the code above...
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
Pull request for 'jg-20061103-00' tag
Please pull from tag 'jg-20061103-00' in repository
git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git jg-20061103-00
to get the changes below.
Distance from 'upstream-fixes'
-
17fddc34b36fc26aa8b5f130fe32b446d9d88fa2
Diffstat
drivers/net/r8169.c | 22 --
1 files changed, 20 insertions(+), 2 deletions(-)
Shortlog
Francois Romieu:
r8169: perform a PHY reset before any other operation at boot time
Patch
-
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 27f90b2..50b753d 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -571,8 +571,8 @@ static void rtl8169_xmii_reset_enable(vo
{
unsigned int val;
- val = (mdio_read(ioaddr, MII_BMCR) | BMCR_RESET) 0x;
- mdio_write(ioaddr, MII_BMCR, val);
+ mdio_write(ioaddr, MII_BMCR, BMCR_RESET);
+ val = mdio_read(ioaddr, MII_BMCR);
}
static void rtl8169_check_link_status(struct net_device *dev,
@@ -1406,6 +1406,22 @@ static void rtl8169_release_board(struct
free_netdev(dev);
}
+static void rtl8169_phy_reset(struct net_device *dev,
+ struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp-mmio_addr;
+ int i;
+
+ tp-phy_reset_enable(ioaddr);
+ for (i = 0; i 100; i++) {
+ if (!tp-phy_reset_pending(ioaddr))
+ return;
+ msleep(1);
+ }
+ if (netif_msg_link(tp))
+ printk(KERN_ERR %s: PHY reset failed.\n, dev-name);
+}
+
static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private
*tp)
{
void __iomem *ioaddr = tp-mmio_addr;
@@ -1434,6 +1450,8 @@ static void rtl8169_init_phy(struct net_
rtl8169_link_option(board_idx, autoneg, speed, duplex);
+ rtl8169_phy_reset(dev, tp);
+
rtl8169_set_speed(dev, autoneg, speed, duplex);
if ((RTL_R8(PHYstatus) TBI_Enable) netif_msg_link(tp))
--
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: [PATCH 3/6] d80211: add a perm_addr hardware property
On Thursday 02 November 2006 17:38, Johannes Berg wrote: After removing knowledge of the master net_dev from drivers, they'll still need a way to tell us which MAC address they have. This is that way, the perm_addr is initially used for all devices. Shouldn't you add something to ieee80211_set_mac_address so the driver/d80211 can find out what MAC address the user actually wants? Might be easier to just point perm_addr to dev_addr, but that would make it obvious that perm_addr is a bit messy. A wrapper for drivers that returns a pointer to dev_addr might be a better idea. Also, do we need to update interfaces associated with the master interface when the master MAC address changes? -Michael Wu pgpGDCT9RsJnl.pgp Description: PGP signature
Re: [PATCH 0/6] rework d80211 cookie pointer
On Friday 03 November 2006 14:08, Johannes Berg wrote: Yeah, I thought about that and added that function to get the wiphy index. cfg80211 makes the wiphy index an actual identifier that you can use to enumerate all devices it has attached etc, so that makes sense. and d80211 also puts it into sysfs. Is that good enough? I still prefer obtaining the name of the master interface because well.. all other network drivers prefix their messages with the name of their interface. The master interface name should be as good as the wiphy index to enumerate attached devices. -Michael Wu pgpSjDUVGYY8u.pgp Description: PGP signature
Re: [take22 0/4] kevent: Generic event handling mechanism.
On Wed, Nov 01, 2006 at 09:57:46PM +0300, Evgeniy Polyakov wrote: On Wed, Nov 01, 2006 at 06:20:43PM +, Oleg Verych ([EMAIL PROTECTED]) wrote: [] Where's real-life application to do configure make make install? Your real life or mine as developer? I fortunately do not know anything about your real life, but my real life To do not further shift conversation in no technical way, think of my sentence as question *and* as definition. applications can be found on project's homepage. There is a link to archive there, where you can find plenty of sources. But no single makefile. Or what CC and options do not mater really? You can easily find in your server's apache logs, my visit of that archive in the day of my message (today i just confirmed my assertions): browser lynx, host flower.upol.cz. You likely do not know, but it is a bit risky business to patch all existing applications to show that approach is correct, if implementation is not completed. Fortunately to me, `lighthttpd' is real-life *and* in the benchmark area also. Just see that site how much there was measured: different OSes, special tunning. *That* is i'm talking about. Epoll _wrapper_ there, is 3461 byte long, your answer to _me_ 2580. People are bringing you a test bed, with all set up ready to use; need less code, go on, comment needless out! You likely do not know, but after I first time announced kevents in February I changed interfaces 4 times - and it is just interfaces, not including numerous features added/removed by developer's requests. I think that called open source, linux kernel case. There were some comments about laking much of such programs, answers were was in prev. e-mail, need to update them, something like that. Trivial web server sources url, mentioned in benchmark isn't pointed in patch advertisement. If it was, should i actually try that new *trivial* wheel? Answer is trivial - there is archive where one can find a source code (filenames are posted regulary). Should I create a rpm? For what glibc version? Hmm. Let me answer on that dup with stuff from LKML archive. That will reveal, that my guesses were told by The Big Jury to you already: [^0] Message-ID: [EMAIL PROTECTED] [^1] Message-ID: [EMAIL PROTECTED], Message-ID: [EMAIL PROTECTED] more than 10 takes ago. Saying that, i want to give you some short examples, i know. *Linux kernel - userspace*: o Alexey Kuznetsov networking - (excellent) iproute set of utilities; iproute documentation was way too bad when Alexey presented it first time :) As example, after have read some books on TCP/IP and Ethernet, internal help of `ip' was all i needed to know. Btw, show me splice() 'shiny' application? Does lighttpd use it? Or move_pages(). You know who proposed that, and you know how many (few) releases ago. To make a little hint to you, Evgeniy, why don't you find a little animal in the open source zoo to implement little interface to proposed kernel subsystem and then show it to The Big Jury (not me), we have here? And i can not see, how you've managed to implement something like that having almost nothing on the test basket. Very *suspicious* ch. There are always people who do not like something, what can I do with I didn't think, that my message was offensive. Also i didn't even say, that you have not bothered feed your code to scripts/Lindent. [] I created trivial web servers, which send single static page and use various event handling schemes, and I test new subsystem with new tools, when tests are completed and all requested features are implemented it is time to work on different more complex users. Please, see [^0], So let's at least complete what we have right now, so no developer's efforts could be wasted writing empty chars in various places. and [^1]. [ Please do not answer just to answer, cc list is big, no one from ] [ The Big Jury seems to care. (well, Jonathan does, but he wasn't in cc) ] Friendly, Oleg. - 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 4/6] d80211: add a struct device* hardware property
On Thursday 02 November 2006 17:38, Johannes Berg wrote: + /* hardware device */ + struct device *dev; + Can we just pass this in as an argument instead? No one is gonna look at it ever again after ieee80211_register_hw, so I don't think it's worth putting in struct ieee80211_hw. + local-mdev-class_dev.dev = hw-dev; Why not use SET_NETDEV_DEV? -Michael Wu pgpED2SctxFK0.pgp Description: PGP signature
Re: [PATCH 5/6] d80211: add a ethtool_ops hardware property
On Thursday 02 November 2006 17:39, Johannes Berg wrote: After removing knowledge of the master net_dev from drivers, some will still want to have ethtool ops assigned (rt2x00 uses it). This is that way. But bcm43xx sets ethtool ops through bcm43xx_netdev_setup. Why not have rt2x00 do the same? Then we won't have to go through all the trouble of adding things to ieee80211_hw and ieee80211_register_hw to set things in net_device. This would work out pretty well for SET_NETDEV_DEV too. -Michael Wu pgpIZyGVpJaIw.pgp Description: PGP signature
RE: [patch] d80211: use pfifo_qdisc_ops rather thand80211-specificqdisc
On Fri, 2006-11-03 at 11:23 -0800, Simon Barber wrote: I would think the master device is the perfect place to do packet capture, Sort of. Since it'll be an 802.11 protocol thing, you won't be getting any signal strength information etc. You really do need that. and raw packet transmission. Same here, you really do want to be able to submit a frame with the bitrate to use etc. All not part of 802.11. All the meta info you want from RX or need for proper TX cannot be transported over that master netdev since it'll have a proper 802.11 protocol, so it's pretty much useless. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/6] rework d80211 cookie pointer
On Fri, 2006-11-03 at 17:14 -0500, Michael Wu wrote: I still prefer obtaining the name of the master interface because well.. all other network drivers prefix their messages with the name of their interface. The master interface name should be as good as the wiphy index to enumerate attached devices. I'm trying to get rid of the master interface mostly. I can surely add a way to get it if we finally decide that we want/need to keep it. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH 3/6] d80211: add a perm_addr hardware property
On Fri, 2006-11-03 at 16:49 -0500, Michael Wu wrote: Shouldn't you add something to ieee80211_set_mac_address so the driver/d80211 can find out what MAC address the user actually wants? Hmm? d80211 already handles the case of the user changing a net_dev's mac address fine. And it'll tell your driver about it whenever it matters, at the time the user tries to UP that interface. And other than that, the driver doesn't care. Might be easier to just point perm_addr to dev_addr, but that would make it obvious that perm_addr is a bit messy. A wrapper for drivers that returns a pointer to dev_addr might be a better idea. I don't understand this. perm_addr is a field in the ieee80211_hw struct reflecting the permanent mac address of the card. What's wrong with that? Also, do we need to update interfaces associated with the master interface when the master MAC address changes? No. The interfaces are allowed to have differing mac addresses. But I think they should all start out with the permanent mac address which is why I put that field there. I guess you could argue for always using the master's mac address. I would prefer new devices to start out with the permanent mac address, but we can change that. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH 5/6] d80211: add a ethtool_ops hardware property
On Fri, 2006-11-03 at 17:43 -0500, Michael Wu wrote: But bcm43xx sets ethtool ops through bcm43xx_netdev_setup. Why not have rt2x00 do the same? Actually, look closer. I removed bcm43xx_netdev_setup as well as the setup() callback for the hw as well as the bcm43xx ethtool ops which were useless anyway. Then we won't have to go through all the trouble of adding things to ieee80211_hw and ieee80211_register_hw to set things in net_device. This would work out pretty well for SET_NETDEV_DEV too. No. We have to add these things anyway if we want them copied to the slave netdevs. Besides, the driver has no business mucking with the netdevs. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH 4/6] d80211: add a struct device* hardware property
On Fri, 2006-11-03 at 17:27 -0500, Michael Wu wrote: On Thursday 02 November 2006 17:38, Johannes Berg wrote: + /* hardware device */ + struct device *dev; + Can we just pass this in as an argument instead? No one is gonna look at it ever again after ieee80211_register_hw, so I don't think it's worth putting in struct ieee80211_hw. Actually, it is used for all new devices as well. Yeah, we could pull it out of the mdev again, but it feels stupid to go to so many indirections. The code is already barely understandable. I had a hard time cleaning up the places where struct net_device * is passed, but the only thing it's ever used for is deref'ing -ieee80211_ptr to get local. + local-mdev-class_dev.dev = hw-dev; Why not use SET_NETDEV_DEV? You're right, it should use that. johannes signature.asc Description: This is a digitally signed message part
Wake On Lan device semantics
I am working on getting WOL to work on sky2 (and then skge). But in the process I noticed that the semantics of WOL seems to be device dependent. I assume that WOL should work when device is suspended. But some drivers also support WOL when the device is down (or even removed). Now I know some distro's like Ubuntu take down and then remove every network device on suspend. That's their problem, if they don't want to use suspend as intended because they want to handle broken hardware, that's their problem. It doesn't seem like a good idea for a network device to wake the system if it is down. Maybe if the kernel fully supported dormant, maybe, but when device is down it shouldn't impact the system. -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wake On Lan device semantics
Stephen Hemminger wrote: It doesn't seem like a good idea for a network device to wake the system if it is down. before suspend existed this was the only useful case for WoL. Why does it not seem a good idea to wake up a machine that was shutdown (and thus the interface `downed`) ? Auke - 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 4/6] d80211: add a struct device* hardware property
On Sat, 2006-11-04 at 00:21 +0100, Johannes Berg wrote: Actually, it is used for all new devices as well. Yeah, we could pull it out of the mdev again, Oh, in fact, we do. I still think it feels stupid and will change it. johannes signature.asc Description: This is a digitally signed message part
Re: Wake On Lan device semantics
On Fri, 03 Nov 2006 15:44:13 -0800 Auke Kok [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: It doesn't seem like a good idea for a network device to wake the system if it is down. before suspend existed this was the only useful case for WoL. Why does it not seem a good idea to wake up a machine that was shutdown (and thus the interface `downed`) ? Auke It seems odd because that means you can never make a device fully deaf. -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wake On Lan device semantics
On Fri, 03 Nov 2006 15:44:13 -0800 Auke Kok [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: It doesn't seem like a good idea for a network device to wake the system if it is down. before suspend existed this was the only useful case for WoL. Why does it not seem a good idea to wake up a machine that was shutdown (and thus the interface `downed`) ? Auke Interestingly it looks like e100 is one of the ones that only wakes from suspend (not when down). -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wake On Lan device semantics
Stephen Hemminger wrote: I am working on getting WOL to work on sky2 (and then skge). But in the process I noticed that the semantics of WOL seems to be device dependent. I assume that WOL should work when device is suspended. But some drivers also support WOL when the device is down (or even removed). [...] It doesn't seem like a good idea for a network device to wake the system if it is down. Maybe if the kernel fully supported dormant, maybe, but when device is down it shouldn't impact the system. You seem to be muddling device, driver, and system together. The purpose of WOL is being able to turn on a system remotely, if it is in a power-off or sleep state. So, if the system is -on- and the interface is down and/or driver is unloaded, are you saying WOL is a problem somehow? 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: Wake On Lan device semantics
From: Jeff Garzik [EMAIL PROTECTED] Date: Fri, 03 Nov 2006 18:51:25 -0500 The purpose of WOL is being able to turn on a system remotely, if it is in a power-off or sleep state. So, if the system is -on- and the interface is down and/or driver is unloaded, are you saying WOL is a problem somehow? Stephen is saying that if you down an interface, it should disable that WoL functionality. I guess you can argue that, like IP addresses, this WoL thing is an attribute of the system. - 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: Wake On Lan device semantics
On Fri, 03 Nov 2006 16:02:30 -0800 (PST) David Miller [EMAIL PROTECTED] wrote: From: Jeff Garzik [EMAIL PROTECTED] Date: Fri, 03 Nov 2006 18:51:25 -0500 The purpose of WOL is being able to turn on a system remotely, if it is in a power-off or sleep state. So, if the system is -on- and the interface is down and/or driver is unloaded, are you saying WOL is a problem somehow? Stephen is saying that if you down an interface, it should disable that WoL functionality. I guess you can argue that, like IP addresses, this WoL thing is an attribute of the system. Looking harder. The semantic needs to be WOL is okay if driver is loaded and device is up or down. But the default for WOL should be disabled until enabled by ethtool (or parameter). -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wake On Lan device semantics
David Miller wrote: From: Jeff Garzik [EMAIL PROTECTED] Date: Fri, 03 Nov 2006 18:51:25 -0500 The purpose of WOL is being able to turn on a system remotely, if it is in a power-off or sleep state. So, if the system is -on- and the interface is down and/or driver is unloaded, are you saying WOL is a problem somehow? Stephen is saying that if you down an interface, it should disable that WoL functionality. Many distros down the interface on poweroff, a state from which WOL is often used, so we don't want this. I guess you can argue that, like IP addresses, this WoL thing is an attribute of the system. Yeah, it's definitely a system state. When the magic packet arrives, the WOL wire on the motherboard is tickled, turning the machine on. 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: Wake On Lan device semantics
From: Jeff Garzik [EMAIL PROTECTED] Date: Fri, 03 Nov 2006 19:42:49 -0500 David Miller wrote: I guess you can argue that, like IP addresses, this WoL thing is an attribute of the system. Yeah, it's definitely a system state. When the magic packet arrives, the WOL wire on the motherboard is tickled, turning the machine on. Ok, and Stephen seems to agree now too on this point. I think there is merit to Stephen's assertion that WoL should be off by default. It allows remote entities to do something to your computer. I'm happy to hear counter-arguments, of course :-) - 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: Kernel oops in rt_check_expire()
Gaurav wrote: Hi All, I am seeing a crash in rt_check_expire. Below is the Oops info. Does any one has an idea about the cause of this? Thanks in advance. Regards, Gaurav --- CPU 0 Unable to handle kernel paging request at virtual address 01010020, epc == 8028c28c, ra == 802 Oops in arch/mips/mm/fault.c::do_page_fault, line 171[#1]: Cpu 0 $ 0 : 1000fc01 0010 0001 $ 4 : 01ff 80378000 8043 80539640 $ 8 : 8042 $12 : 80b2b7e0 0003 0009 0003 $16 : 0101 ea60 80378000 005808d1 $20 : 0020 0040 00415e60 $24 : c006a24c $28 : 8046c000 8046de98 0100 8028c30c Hi: Lo: epc : 8028c2f0 rt_check_expire+0xfc/0x234 Tainted: PF ra: 8028c30c rt_check_expire+0x118/0x234 Status: 1000fc03KERNEL EXL IE Cause : 1088 BadVA : 01010020 PrId : 0001800a Modules linked in: ctlmtel ctlmatm ctlmeth ctlmdsl ctlmapi ctlm_sf ctlmspi Process ksoftirqd/0 (pid: 2, threadinfo=8046c000, task=804647c0) Stack : 8041cc90 8042 c006a24c 0020 8028c1f4 8046def0 8041b40c 00200200 00100100 8031 8041b414 8031 801338d8 802f 8026a7fc 80b87c00 8046def0 c006a24c 80b7ff10 80b7ff10 0002 8041b190 0001 0004 802f 8041cc90 8042 802f 8012da80 8012e7c4 0002 80469ef0 8012e694 8042 0002 ... Call Trace: [c006a24c] iad_osal_mutexGive+0x0/0xc0 [ctlmspi] [8028c1f4] rt_check_expire+0x0/0x234 [801338d8] run_timer_softirq+0x51c/0xaa4 [8026a7fc] net_rx_action+0xd8/0x2a8 [c006a24c] iad_osal_mutexGive+0x0/0xc0 [ctlmspi] [8012da80] ___do_softirq+0x90/0x168 [8012e7c4] ksoftirqd+0x130/0x138 [8012e694] ksoftirqd+0x0/0x138 [8012e694] ksoftirqd+0x0/0x138 [8012dc6c] _do_softirq+0x60/0x7c [8012e74c] ksoftirqd+0xb8/0x138 [8012e754] ksoftirqd+0xc0/0x138 [801454c0] kthread+0x268/0x2b0 [801452c8] kthread+0x70/0x2b0 [80103a68] kernel_thread_helper+0x10/0x18 [80103a58] kernel_thread_helper+0x0/0x18 Code: 1212 afb40010 8e020020 02002021 1440fff0 02202821 3c02 8032 0c0a304d note: ksoftirqd/0[2] exited with preempt_count 1 BUG: scheduling while atomic: ksoftirqd/0/0x0001/2 caller is do_exit+0x924/0x12f0 Call Trace: [8012a79c] do_exit+0x924/0x12f0 [802e4f14] __schedule+0x8d0/0xba0 [802e4f0c] __schedule+0x8c8/0xba0 [8041] ip_auto_config+0x338/0x1158 [8012a79c] do_exit+0x924/0x12f0 [80107bfc] __die+0xf8/0x108 [8010c44c] do_page_fault+0x14c/0x3b0 [c008044c] iad_eth_start_xmit+0x180/0x4d4 [ctlmeth] [8028c2f0] rt_check_expire+0xfc/0x234 [8028c30c] rt_check_expire+0x118/0x234 [8041] ip_auto_config+0x338/0x1158 [8014d184] handle_IRQ_event+0x94/0x1cc [8012dd14] do_softirq+0x8c/0xb8 [8012dd14] do_softirq+0x8c/0xb8 [8014d484] __do_IRQ+0x1b0/0x22c [8014d4d0] __do_IRQ+0x1fc/0x22c [80269724] dev_queue_xmit+0x344/0x3ec [802696ec] dev_queue_xmit+0x30c/0x3ec [8012de64] irq_exit+0x5c/0x74 [8014d184] handle_IRQ_event+0x94/0x1cc [801032b4] do_IRQ+0x24/0x3c [801032ac] do_IRQ+0x1c/0x3c [8010ce60] tlb_do_page_fault_0+0x100/0x108 [8014d4d0] __do_IRQ+0x1fc/0x22c [8012de64] irq_exit+0x5c/0x74 [c006a24c] iad_osal_mutexGive+0x0/0xc0 [ctlmspi] [8028c30c] rt_check_expire+0x118/0x234 [8028c2f0] rt_check_expire+0xfc/0x234 [c006a24c] iad_osal_mutexGive+0x0/0xc0 [ctlmspi] [8028c1f4] rt_check_expire+0x0/0x234 [801338d8] run_timer_softirq+0x51c/0xaa4 [8026a7fc] net_rx_action+0xd8/0x2a8 [c006a24c] iad_osal_mutexGive+0x0/0xc0 [ctlmspi] [8012da80] ___do_softirq+0x90/0x168 [8012e7c4] ksoftirqd+0x130/0x138 [8012e694] ksoftirqd+0x0/0x138 [8012e694] ksoftirqd+0x0/0x138 [8012dc6c] _do_softirq+0x60/0x7c [8012e74c] ksoftirqd+0xb8/0x138 [8012e754] ksoftirqd+0xc0/0x138 [801454c0] kthread+0x268/0x2b0 [801452c8] kthread+0x70/0x2b0 [80103a68] kernel_thread_helper+0x10/0x18 [80103a58] kernel_thread_helper+0x0/0x18 --- You would rather post it to lkml and netdev. Please post a kernel version and some other basic info if there is any. regards, -- http://www.fi.muni.cz/~xslaby/ Jiri Slaby - 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: Wake On Lan device semantics
Stephen Hemminger wrote: On Fri, 03 Nov 2006 15:44:13 -0800 Auke Kok [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: It doesn't seem like a good idea for a network device to wake the system if it is down. before suspend existed this was the only useful case for WoL. Why does it not seem a good idea to wake up a machine that was shutdown (and thus the interface `downed`) ? Auke It seems odd because that means you can never make a device fully deaf. sure you can, just turn off WoL and e1000 will really shutdown (at least, I hope :)) Auke - 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: Wake On Lan device semantics
On Fri, 03 Nov 2006 17:36:45 -0800 Auke Kok [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: On Fri, 03 Nov 2006 15:44:13 -0800 Auke Kok [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: It doesn't seem like a good idea for a network device to wake the system if it is down. before suspend existed this was the only useful case for WoL. Why does it not seem a good idea to wake up a machine that was shutdown (and thus the interface `downed`) ? Auke Interestingly it looks like e100 is one of the ones that only wakes from suspend (not when down). that would be a bug, I'll have to get that checked especially after the latest changes to it. Sorry, my bad my test machine was not setup properly. - 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: Wake On Lan device semantics
Stephen Hemminger wrote: On Fri, 03 Nov 2006 15:44:13 -0800 Auke Kok [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: It doesn't seem like a good idea for a network device to wake the system if it is down. before suspend existed this was the only useful case for WoL. Why does it not seem a good idea to wake up a machine that was shutdown (and thus the interface `downed`) ? Auke Interestingly it looks like e100 is one of the ones that only wakes from suspend (not when down). that would be a bug, I'll have to get that checked especially after the latest changes to it. Auke - 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: Wake On Lan device semantics
Stephen Hemminger wrote:
On Fri, 03 Nov 2006 17:36:45 -0800
Auke Kok [EMAIL PROTECTED] wrote:
Stephen Hemminger wrote:
On Fri, 03 Nov 2006 15:44:13 -0800
Auke Kok [EMAIL PROTECTED] wrote:
Stephen Hemminger wrote:
It doesn't seem like a good idea for a network device to wake the system
if it is down.
before suspend existed this was the only useful case for WoL. Why does it not seem a
good idea to wake up a machine that was shutdown (and thus the interface `downed`) ?
Auke
Interestingly it looks like e100 is one of the ones that only wakes from
suspend (not when down).
that would be a bug, I'll have to get that checked especially after the latest changes
to it.
Sorry, my bad my test machine was not setup properly.
I don't blame you, WoL is one of the hardest features to get right, especially with all
the various e100{,0} hardware and options that influence it (manageability, eeproms, etc).
On top of that there's this blob called BIOS messing it all up after a
powercycle :)
Cheers,
Auke
-
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: Wake On Lan device semantics
Stephen Hemminger wrote: On Fri, 03 Nov 2006 16:02:30 -0800 (PST) David Miller [EMAIL PROTECTED] wrote: From: Jeff Garzik [EMAIL PROTECTED] Date: Fri, 03 Nov 2006 18:51:25 -0500 The purpose of WOL is being able to turn on a system remotely, if it is in a power-off or sleep state. So, if the system is -on- and the interface is down and/or driver is unloaded, are you saying WOL is a problem somehow? Stephen is saying that if you down an interface, it should disable that WoL functionality. I guess you can argue that, like IP addresses, this WoL thing is an attribute of the system. Looking harder. The semantic needs to be WOL is okay if driver is loaded and device is up or down. But the default for WOL should be disabled until enabled by ethtool (or parameter). Since this is enabled already in the BIOSes for most systems (or disabled, and switcheable by the user), I'd say we can let the driver handle the default (on for most cards) already. The BIOS can also handle a WoL call after a (long) powerfailure, before the OS boots, so disabling it in the OS would be quite useless in that case: the BIOS would override it anyway. Doesn't sound like a problem you can solve in the driver layer... Cheers, Auke - 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] d80211: use pfifo_qdisc_ops ratherthand80211-specificqdisc
I guess right now when you transmit on the master device frames are only accepted with a cookie and all that info in the CB. It would work just as well to move that info from the CB and into a protocol header. It would also make it easier to expand the info without the size constraint of the CB. Same could apply on receive. Simon -Original Message- From: Johannes Berg [mailto:[EMAIL PROTECTED] Sent: Friday, November 03, 2006 3:07 PM To: Simon Barber Cc: Stephen Hemminger; Christoph Hellwig; James Ketrenos; John W. Linville; Jeff Garzik; Patrick McHardy; David Kimdon; netdev@vger.kernel.org Subject: RE: [patch] d80211: use pfifo_qdisc_ops ratherthand80211-specificqdisc On Fri, 2006-11-03 at 11:23 -0800, Simon Barber wrote: I would think the master device is the perfect place to do packet capture, Sort of. Since it'll be an 802.11 protocol thing, you won't be getting any signal strength information etc. You really do need that. and raw packet transmission. Same here, you really do want to be able to submit a frame with the bitrate to use etc. All not part of 802.11. All the meta info you want from RX or need for proper TX cannot be transported over that master netdev since it'll have a proper 802.11 protocol, so it's pretty much useless. johannes - 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
[Info]d80211 : Understanding d80211
Hi, I wanted to understand the code of d80211 (thanks to James Ketrenos for the info he provided) and also work in it. I found that I can get the latest patches regarding the same from : http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/ Also, in the main kernel tree the development for 802.11 is in drivers/net/wireless/* . Well, I did not find any reference of d80211 in lk 2.6.18.1, though a few places I read that the possible merger would be in lk 2.6.19. I hope I got it right ? Any docs that I can read through that you would recommend from where I can start up ? Is there any place where I can download the code in a similar pattern as we do from kernel.org for the mainstream kernel ? tia, Udayan Tata Consultancy Services India www.tcs.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: [Info]d80211 : Understanding d80211
Udayan Singh wrote: Hi, I wanted to understand the code of d80211 (thanks to James Ketrenos for the info he provided) and also work in it. I found that I can get the latest patches regarding the same from : http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/ Wireless-2.6 contains the developmental version of wireless code _NOT_ using d80211. The d80211 development version is at git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git and must be downloaded with git, not ftp or http. Also, in the main kernel tree the development for 802.11 is in drivers/net/wireless/* . The d80211 drivers are in drivers/net/wireless/d80211/*. The drivers in drivers/net/wireless/* do not use d80211. Well, I did not find any reference of d80211 in lk 2.6.18.1, though a few places I read that the possible merger would be in lk 2.6.19. I hope I got it right ? The merger of d80211 with mainline kernel will occur with 2.6.21 or later. At the moment, there are several reasons for it not to be included in the mainline kernel. The stable kernels (2.6.18.X and earlier), and the mainline developmental kernel (2.6.19-rcX) do not include the d80211 code. Any docs that I can read through that you would recommend from where I can start up ? Only the code AFAIK. Is there any place where I can download the code in a similar pattern as we do from kernel.org for the mainstream kernel ? See the previous git reference. Larry - 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
[2.6 patch] USB_RTL8150 must select MII
On Thu, Nov 02, 2006 at 06:47:15PM -0800, David Brownell wrote: On Thursday 02 November 2006 6:27 pm, Adrian Bunk wrote: It seems to lack the select MII at the USB_RTL8150 option that was in Randy's first patch? I was just addressing the usbnet issues ... that driver doesn't use the usbnet framework. OK, the patch for this driver is below. - Dave cu Adrian -- snip -- USB_RTL8150 must select MII to avoid link errors. Stolen from a patch by Randy Dunlap. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- linux-2619-rc3-pv.orig/drivers/usb/net/Kconfig +++ linux-2619-rc3-pv/drivers/usb/net/Kconfig @@ -84,6 +84,7 @@ config USB_PEGASUS config USB_RTL8150 tristate USB RTL8150 based ethernet device support (EXPERIMENTAL) depends on EXPERIMENTAL + select MII help Say Y here if you have RTL8150 based usb-ethernet adapter. Send me [EMAIL PROTECTED] any comments you may have. - 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
