Re: [PATCH] TCP: Replace __kfree_skb() with kfree_skb()
On Fri, Jan 26, 2007 at 09:45:18PM +1100, Herbert Xu wrote: On Fri, Jan 26, 2007 at 11:18:38AM +0100, Jarek Poplawski wrote: I don't mean it's necessary. I mean now skb is freed unconditionally and after this patch, if there is some error in counting, skb will stay. I thought Masayuki wrote about such possibility, but if I missed his point, then the rest is really O.K. OK, I see what you mean. Now I see what I mean too... And it's very bad! This patch was done to allow more skb-users here, so this debugging would warn mainly about something we've just enabled. I was simply fooled by this change - how it was possible to work all these days? I see, the main idea is: the data from skb is copied at this level only and no cloning (tcp_ipv4). Except tcp_ipv6. So this patch is changing it to ipv6 way. It seems to be quite brave. I think there was some reason to do this old way and I hope consequences were analyzed. There are also other doubts: what decisions are made? According to tcp_rcv_state_process skb should be dropped. tcp_v6_do_rcv seems to have other opinion. And after this change there could be, probably, more such doubtful places. Maybe it would be sufficient to enable this by some additional if and return code from conn_request in the if (th-syn) block? Regards, Jarek P. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.20-rc6-mm1
* Herbert Xu [EMAIL PROTECTED] wrote:
Actually, maybe I was confusing this with the fixes Ingo had for
local_bh_disable vs. preemption in the -rt tree. Ingo, do you have
preemptible RCU support in your -rt tree and if so did you have to fix
the networking stack to behave correctly with it?
yeah, -rt is the main prototyping tree for PREEMPT_RCU, and it has been
included in -rt for 1.5 years or so. There were only some small things
here and there, but with Paul's latest design i dont remember anything
but the occasional place that needs to be marked raw_smp_processor_id().
CONFIG_DEBUG_PREEMPT ought to catch those. I dont remember any big
breakage.
i've just reviewed all changes to net/* in -rt, and the changes below
are the ones that seem to be upstream-relevant.
Ingo
Index: linux/net/ipv4/multipath_wrandom.c
===
--- linux.orig/net/ipv4/multipath_wrandom.c
+++ linux/net/ipv4/multipath_wrandom.c
@@ -301,6 +301,7 @@ static void wrandom_flush(void)
for (i = 0; i MULTIPATH_STATE_SIZE; ++i) {
struct multipath_route *r;
+ rcu_read_lock();
spin_lock_bh(state[i].lock);
list_for_each_entry_rcu(r, state[i].head, list) {
struct multipath_dest *d;
@@ -315,6 +316,7 @@ static void wrandom_flush(void)
}
spin_unlock_bh(state[i].lock);
+ rcu_read_unlock();
}
}
Index: linux/net/ipv4/netfilter/arp_tables.c
===
--- linux.orig/net/ipv4/netfilter/arp_tables.c
+++ linux/net/ipv4/netfilter/arp_tables.c
@@ -245,7 +245,7 @@ unsigned int arpt_do_table(struct sk_buf
read_lock_bh(table-lock);
private = table-private;
- table_base = (void *)private-entries[smp_processor_id()];
+ table_base = (void *)private-entries[raw_smp_processor_id()];
e = get_entry(table_base, private-hook_entry[hook]);
back = get_entry(table_base, private-underflow[hook]);
@@ -955,7 +955,7 @@ static int do_add_counters(void __user *
i = 0;
/* Choose the copy that is on our node */
- loc_cpu_entry = private-entries[smp_processor_id()];
+ loc_cpu_entry = private-entries[raw_smp_processor_id()];
ARPT_ENTRY_ITERATE(loc_cpu_entry,
private-size,
add_counter_to_entry,
Index: linux/net/ipv4/netfilter/ip_tables.c
===
--- linux.orig/net/ipv4/netfilter/ip_tables.c
+++ linux/net/ipv4/netfilter/ip_tables.c
@@ -246,7 +246,7 @@ ipt_do_table(struct sk_buff **pskb,
read_lock_bh(table-lock);
IP_NF_ASSERT(table-valid_hooks (1 hook));
private = table-private;
- table_base = (void *)private-entries[smp_processor_id()];
+ table_base = (void *)private-entries[raw_smp_processor_id()];
e = get_entry(table_base, private-hook_entry[hook]);
/* For return from builtin chain */
Index: linux/net/ipv4/tcp.c
===
--- linux.orig/net/ipv4/tcp.c
+++ linux/net/ipv4/tcp.c
@@ -1138,10 +1138,10 @@ int tcp_recvmsg(struct kiocb *iocb, stru
preempt_disable();
if ((len sysctl_tcp_dma_copybreak) !(flags MSG_PEEK)
!sysctl_tcp_low_latency __get_cpu_var(softnet_data).net_dma) {
- preempt_enable_no_resched();
+ preempt_enable();
tp-ucopy.pinned_list = dma_pin_iovec_pages(msg-msg_iov, len);
} else
- preempt_enable_no_resched();
+ preempt_enable();
#endif
do {
Index: linux/net/ipv6/netfilter/ip6_tables.c
===
--- linux.orig/net/ipv6/netfilter/ip6_tables.c
+++ linux/net/ipv6/netfilter/ip6_tables.c
@@ -282,7 +282,7 @@ ip6t_do_table(struct sk_buff **pskb,
read_lock_bh(table-lock);
private = table-private;
IP_NF_ASSERT(table-valid_hooks (1 hook));
- table_base = (void *)private-entries[smp_processor_id()];
+ table_base = (void *)private-entries[raw_smp_processor_id()];
e = get_entry(table_base, private-hook_entry[hook]);
/* For return from builtin chain */
@@ -1097,7 +1097,7 @@ do_add_counters(void __user *user, unsig
i = 0;
/* Choose the copy that is on our node */
- loc_cpu_entry = private-entries[smp_processor_id()];
+ loc_cpu_entry = private-entries[raw_smp_processor_id()];
IP6T_ENTRY_ITERATE(loc_cpu_entry,
private-size,
add_counter_to_entry,
Index: linux/net/xfrm/xfrm_user.c
===
--- linux.orig/net/xfrm/xfrm_user.c
+++ linux/net/xfrm/xfrm_user.c
@@ -1273,13 +1273,12 @@ static int
Re:[patch]IPv6:fix BUG of ndisc_send_redirect()
Mr David:
I have submitted a patch to fix the ndisc_send_resirect(), and this
patch has been agreed by Mr yoshifuji. But you have not applied yet.
The following is Mr yoshifuji's reply, and I submitted the patch again.
In article [EMAIL PROTECTED] (at Sat, 13
Jan 2007 17:12:40 +0800), Li Yewang [EMAIL PROTECTED] says:
When I tested IPv6 redirect function about kernel 2.6.19.1, and
found
that the kernel can send redirect packets whose target address is
global
address, and the target is not the actual endpoint of communication.
:
So, I think the send redirect function must check the target address
also.
It is not mandatory, however, it is better to do this. I agree.
(Note: In usual, we do not install gateway'ed route with global
next-hop.)
Acked-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
--yoshfuji
Following is my patch:
signed-off-by: Li Yewang [EMAIL PROTECTED]
--- a/net/ipv6/ndisc.c 2007-01-29 18:12:35.036415512 +0800
+++ b/net/ipv6/ndisc.c 2007-01-13 17:02:02.0 +0800
@@ -1412,6 +1412,13 @@ void ndisc_send_redirect(struct sk_buff
return;
}
+ if (!ipv6_addr_equal(skb-nh.ipv6h-daddr, target)
+ !(ipv6_addr_type(target) IPV6_ADDR_LINKLOCAL)) {
+ ND_PRINTK2(KERN_WARNING
+ ICMPv6 Redirect: target address is not link-
local.\n);
+ return;
+ }
+
ndisc_flow_init(fl, NDISC_REDIRECT, saddr_buf, skb-nh.ipv6h-
saddr,
dev-ifindex);
-
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: r8169: Crash after reloading driver if network hangs
Hello, * Francois Romieu [EMAIL PROTECTED] [2007-01-29 08:56]: Bernhard Walle [EMAIL PROTECTED] : @@ -1371,10 +1371,9 @@ static inline void rtl8169_request_timer return; init_timer(timer); - timer-expires = jiffies + RTL8169_PHY_TIMEOUT; timer-data = (unsigned long)(dev); timer-function = rtl8169_phy_timer; - add_timer(timer); + mod_timer(timer, jiffies + RTL8169_PHY_TIMEOUT); } But I think _this_ change is unnecessary, ... add_timer() is not supposed to modify an existing timer whereas mod_timer() encompasses both that's clear. and the race exists in both direction as netif_running() is true as soon as dev_open() starts but way before dev-open() completes. But rtl8169_request_timer() is only called from change_mtu() and dev-open(). And, if you call init_timer(), you always have a new timer, and the reference to an existing tp-timer will be lost. [...] ... but that looks good (better than my patch) and should resolve the issue, too. I can't test because it's triggered only if the network hangs and you know, the last one isn't reproducable. There will be something to test in the merge of realtek's stuff #2. Great. Regards, Bernhard -- SUSE LINUX Products GmbHE-Mail: [EMAIL PROTECTED] Maxfeldstr. 5 Phone: +49 (911) 74053-0 90409 Nürnberg, Germany OpenPGP DDAF6454: F61F 34CC 09CA FB82 C9F6 BA4B 8865 3696 DDAF 6454 - 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] TCP: Replace __kfree_skb() with kfree_skb()
On Mon, Jan 29, 2007 at 09:26:16AM +0100, Jarek Poplawski wrote: ... So this patch is changing it to ipv6 way. It seems to be quite brave. I think there was some reason to do this old way and I hope consequences were analyzed. ... But since Alexey Kuznetsov accepted this change too, they surely were. Let's forget about my doubts. Sorry for disturbing, Jarek P. - 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: Hidden SSID's
On Sat, 2007-01-27 at 07:08 -0500, Dan Williams wrote: I really, really don't know why ieee80211 uses hidden, but it's a pain in the ass and should NOT be done for d80211. I don't know if we can ever remove it from ieee80211 though for backwards compat reasons. Ugh. /me makes a note for the cfg80211/we compat layer. This is a mess :( johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH] zd1211rw: Reset device in the probe call
On Mon, Jan 29, 2007 at 01:00:15AM +, Daniel Drake wrote: From: Ulrich Kunitz [EMAIL PROTECTED] This resets the device in the probe call. It does work with 2.6.19.2 including the softmac patches. It might fix the reboot/reset problems a lot of people reported. Looks like you sent this one twice. Is this just a duplicate? Or did you mean to send a different patch? 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: [PATCH] zd1211rw: Reset device in the probe call
John W. Linville wrote: Looks like you sent this one twice. Is this just a duplicate? Or did you mean to send a different patch? Sent twice by accident. Ignore the duplicate and you have the whole series. Thanks, Daniel - 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] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
On Fri, Jan 26, 2007 at 04:42:41PM -0500, Vlad Yasevich wrote: Neil Horman wrote: On Fri, Jan 26, 2007 at 03:28:40PM -0500, Vlad Yasevich wrote: Hi Neil Neil Horman wrote: On Fri, Jan 26, 2007 at 09:13:31AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote: In article [EMAIL PROTECTED] (at Thu, 25 Jan 2007 14:45:00 -0500), Neil Horman [EMAIL PROTECTED] says: New patch attached with most of your suggestions incorporated. I've a few comments mixed in for some of the suggestions that I think need further discussion If optimistic_dad is disabled, flags should be IFA_F_TEMPORARY, not IFA_F_TEMPORARY|IFA_F_OPTIMISTIC. Another idea is to use IFA_F_OPTIMISTIC not IFA_F_OPTIMISTIC|IFA_F_TENTATIVE until the DAD has been finished. I'm currently setting the OPTIMISTIC flag in every location that its possibly needed, and then clearing it in addrconf_dad_start if that interface is not participating in optimistic dad. I do this because the RFC in section 3.1 indicates that manually configured addresses should not set the optimistic flag. If I removed the OPTIMISTIC flag from the locations it gets set in the patch and then only set it for participating interfaces in addrconf_dad_start, I would need to have some way to tell if the address in question was manually configured (to avoid setting it in that case). At present I see no clear way to do that, but if you have a suggestion, I'll happily change this around. One suggestiong/question: Instead of clearing the OPTIMISTIC flag in addrconf_dad_start(), wouldn't it be better to simply not set the flag in ipv6_add_addr()? Just mask that flag from the 'flags' argument passed to that function when conditions are right. Doh! Sometimes I don't just think straight. Yes, as long as ipv6_add_addr is only for adding static addresses (which it pretty clearly is), that would work much better. I'll fix it up and repost on monday. Don't suppose you have any thoughts on how to solve the send to default router problem, do you? Still trying to figure how the routing side works. sorry -vlad I've got your flag changes made, but I'm holding off on reposting for a bit. Dave M. just gave me some advice on how best to handle the default router case. Trying to understand the routing code and integrate that before I repost. Thanks Neil - 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] d80211: use invisible network device for wmaster
Use register_invisible_netdevice for master interface.
Signed-off-by: Jiri Benc [EMAIL PROTECTED]
---
net/d80211/ieee80211.c | 22 ++
net/d80211/ieee80211_iface.c |8 ++--
2 files changed, 8 insertions(+), 22 deletions(-)
--- dscape.orig/net/d80211/ieee80211.c
+++ dscape/net/d80211/ieee80211.c
@@ -4540,23 +4540,11 @@ int ieee80211_register_hw(struct ieee802
memcpy(local-mdev-dev_addr, local-hw.perm_addr, ETH_ALEN);
SET_NETDEV_DEV(local-mdev, local-hw.dev);
- result = register_netdevice(local-mdev);
+ result = register_invisible_netdevice(local-mdev);
if (result 0) {
rtnl_unlock();
goto fail_dev;
}
- result = sysfs_create_link(local-class_dev.kobj,
- local-mdev-class_dev.kobj,
- master);
- if (result 0) {
- rtnl_unlock();
- goto fail_masterlink;
- }
- result = ieee80211_sysfs_add_netdevice(local-mdev);
- if (result 0) {
- rtnl_unlock();
- goto fail_if_sysfs;
- }
result = ieee80211_init_rate_ctrl_alg(local, NULL);
rtnl_unlock();
@@ -4593,11 +4581,7 @@ int ieee80211_register_hw(struct ieee802
fail_wep:
rate_control_deinitialize(local);
fail_rate:
- ieee80211_sysfs_remove_netdevice(local-mdev);
-fail_if_sysfs:
- sysfs_remove_link(local-class_dev.kobj, master);
-fail_masterlink:
- unregister_netdev(local-mdev);
+ unregister_invisible_netdevice(local-mdev);
fail_dev:
sta_info_stop(local);
fail_sta_info:
@@ -4655,8 +4639,6 @@ void ieee80211_unregister_hw(struct ieee
if (local-apdev)
ieee80211_if_del_mgmt(local);
- sysfs_remove_link(local-class_dev.kobj, master);
-
list_for_each_entry_safe(sdata, tmp, local-sub_if_list, list)
__ieee80211_if_del(local, sdata);
--- dscape.orig/net/d80211/ieee80211_iface.c
+++ dscape/net/d80211/ieee80211_iface.c
@@ -309,8 +309,12 @@ void __ieee80211_if_del(struct ieee80211
struct net_device *dev = sdata-dev;
list_del(sdata-list);
- ieee80211_sysfs_remove_netdevice(dev);
- unregister_netdevice(dev);
+ if (dev == local-mdev)
+ unregister_invisible_netdevice(dev);
+ else {
+ ieee80211_sysfs_remove_netdevice(dev);
+ unregister_netdevice(dev);
+ }
/* Except master interface, the net_device will be freed by
* net_device-destructor (i. e. ieee80211_if_free). */
}
-
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
[RFC PATCH 1/6] invisible network devices
The d80211 stack needs a network interface (called 'wmaster') used for
communication with the hardware (it has 802.11 qdisc attached which perform
MAC level QoS). This interface is not intended for users and it confuses
them.
As a short time solution, this patch allows net_device to be registered as
invisible. This means it is not in the dev name hash list, its ifindex is
-1 and protocols are not notified about its registration/unregistration.
Signed-off-by: Jiri Benc [EMAIL PROTECTED]
---
include/linux/netdevice.h |2
net/core/dev.c| 223 ++
2 files changed, 151 insertions(+), 74 deletions(-)
--- dscape.orig/include/linux/netdevice.h
+++ dscape/include/linux/netdevice.h
@@ -975,6 +975,8 @@ extern struct net_device *alloc_netdev(i
void (*setup)(struct net_device *));
extern int register_netdev(struct net_device *dev);
extern voidunregister_netdev(struct net_device *dev);
+extern int register_invisible_netdevice(struct net_device *dev);
+extern voidunregister_invisible_netdevice(struct net_device *dev);
/* Functions used for multicast support */
extern voiddev_mc_upload(struct net_device *dev);
extern int dev_mc_delete(struct net_device *dev, void *addr, int
alen, int all);
--- dscape.orig/net/core/dev.c
+++ dscape/net/core/dev.c
@@ -2891,37 +2891,10 @@ static inline void net_set_todo(struct n
spin_unlock(net_todo_list_lock);
}
-/**
- * register_netdevice - register a network device
- * @dev: device to register
- *
- * Take a completed network device structure and add it to the kernel
- * interfaces. A %NETDEV_REGISTER message is sent to the netdev notifier
- * chain. 0 is returned on success. A negative errno code is returned
- * on a failure to set up the device, or if the name is a duplicate.
- *
- * Callers must hold the rtnl semaphore. You may want
- * register_netdev() instead of this.
- *
- * BUGS:
- * The locking appears insufficient to guarantee two parallel registers
- * will not get the same name.
- */
-
-int register_netdevice(struct net_device *dev)
+static int init_netdevice(struct net_device *dev)
{
- struct hlist_head *head;
- struct hlist_node *p;
int ret;
- BUG_ON(dev_boot_phase);
- ASSERT_RTNL();
-
- might_sleep();
-
- /* When net_device's are persistent, this will be fatal. */
- BUG_ON(dev-reg_state != NETREG_UNINITIALIZED);
-
spin_lock_init(dev-queue_lock);
spin_lock_init(dev-_xmit_lock);
dev-xmit_lock_owner = -1;
@@ -2929,7 +2902,7 @@ int register_netdevice(struct net_device
spin_lock_init(dev-ingress_lock);
#endif
- dev-iflink = -1;
+ dev-iflink = dev-ifindex = -1;
/* Init, if this function is available */
if (dev-init) {
@@ -2940,27 +2913,13 @@ int register_netdevice(struct net_device
goto out;
}
}
-
- if (!dev_valid_name(dev-name)) {
- ret = -EINVAL;
- goto out;
- }
-
- dev-ifindex = dev_new_index();
- if (dev-iflink == -1)
- dev-iflink = dev-ifindex;
-
- /* Check for existence of name */
- head = dev_name_hash(dev-name);
- hlist_for_each(p, head) {
- struct net_device *d
- = hlist_entry(p, struct net_device, name_hlist);
- if (!strncmp(d-name, dev-name, IFNAMSIZ)) {
- ret = -EEXIST;
- goto out;
- }
- }
+ ret = 0;
+out:
+ return ret;
+}
+static void setup_netdevice(struct net_device *dev)
+{
/* Fix illegal SG+CSUM combinations. */
if ((dev-features NETIF_F_SG)
!(dev-features NETIF_F_ALL_CSUM)) {
@@ -2999,17 +2958,75 @@ int register_netdevice(struct net_device
if (!dev-rebuild_header)
dev-rebuild_header = default_rebuild_header;
- ret = netdev_register_sysfs(dev);
- if (ret)
- goto out;
- dev-reg_state = NETREG_REGISTERED;
-
/*
* Default initial state at registry is that the
* device is present.
*/
set_bit(__LINK_STATE_PRESENT, dev-state);
+}
+
+/**
+ * register_netdevice - register a network device
+ * @dev: device to register
+ *
+ * Take a completed network device structure and add it to the kernel
+ * interfaces. A %NETDEV_REGISTER message is sent to the netdev notifier
+ * chain. 0 is returned on success. A negative errno code is returned
+ * on a failure to set up the device, or if the name is a duplicate.
+ *
+ * Callers must hold the rtnl semaphore. You may want
+ * register_netdev() instead of this.
+ *
+ * BUGS:
+ * The locking appears insufficient to guarantee two parallel
[PATCH 3/6] d80211: drop packets from nonexisting interfaces in PS mode
In a power saving mode, packets queued by devices that meanwhile disappeared
has to be discarded.
Signed-off-by: Jiri Benc [EMAIL PROTECTED]
---
net/d80211/ieee80211.c | 46 +-
1 files changed, 25 insertions(+), 21 deletions(-)
--- dscape.orig/net/d80211/ieee80211.c
+++ dscape/net/d80211/ieee80211.c
@@ -1104,10 +1104,10 @@ static int inline is_ieee80211_device(st
/* Device in tx-dev has a reference added; use dev_put(tx-dev) when
* finished with it. */
-static void inline ieee80211_tx_prepare(struct ieee80211_txrx_data *tx,
- struct sk_buff *skb,
- struct net_device *mdev,
- struct ieee80211_tx_control *control)
+static int inline ieee80211_tx_prepare(struct ieee80211_txrx_data *tx,
+ struct sk_buff *skb,
+ struct net_device *mdev,
+ struct ieee80211_tx_control *control)
{
struct ieee80211_tx_packet_data *pkt_data;
struct net_device *dev;
@@ -1118,13 +1118,10 @@ static void inline ieee80211_tx_prepare(
dev_put(dev);
dev = NULL;
}
- if (unlikely(!dev)) {
- printk(KERN_WARNING %s: NULL ifindex in pkt_data\n,
- mdev-name);
- dev = mdev;
- dev_hold(dev);
- }
+ if (unlikely(!dev))
+ return -ENODEV;
__ieee80211_tx_prepare(tx, skb, dev, control);
+ return 0;
}
static inline int __ieee80211_queue_stopped(struct ieee80211_local *local,
@@ -1815,20 +1812,27 @@ ieee80211_get_buffered_bc(struct ieee802
if (bss-dtim_count != 0)
return NULL; /* send buffered bc/mc only after DTIM beacon */
- skb = skb_dequeue(bss-ps_bc_buf);
memset(control, 0, sizeof(*control));
- if (!skb)
- return NULL;
- local-total_ps_buffered--;
+ while (1) {
+ skb = skb_dequeue(bss-ps_bc_buf);
+ if (!skb)
+ return NULL;
+ local-total_ps_buffered--;
- if (!skb_queue_empty(bss-ps_bc_buf) skb-len = 2) {
- struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb-data;
- /* more buffered multicast/broadcast frames == set MoreData
-* flag in IEEE 802.11 header to inform PS STAs */
- hdr-frame_control |= cpu_to_le16(IEEE80211_FCTL_MOREDATA);
- }
+ if (!skb_queue_empty(bss-ps_bc_buf) skb-len = 2) {
+ struct ieee80211_hdr *hdr =
+ (struct ieee80211_hdr *) skb-data;
+ /* more buffered multicast/broadcast frames == set
+* MoreData flag in IEEE 802.11 header to inform PS
+* STAs */
+ hdr-frame_control |=
+ cpu_to_le16(IEEE80211_FCTL_MOREDATA);
+ }
- ieee80211_tx_prepare(tx, skb, local-mdev, control);
+ if (ieee80211_tx_prepare(tx, skb, local-mdev, control) == 0)
+ break;
+ dev_kfree_skb_any(skb);
+ }
sta = tx.sta;
tx.u.tx.ps_buffered = 1;
-
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 4/6] d80211: don't display name of invisible network device
Invisible master interface does not have meaningful name. Display the wiphy
identifier in kernel messages instead.
Also, remove the allocation of master interface name as it is purposeless
now.
Signed-off-by: Jiri Benc [EMAIL PROTECTED]
---
net/d80211/ieee80211.c | 98 +---
net/d80211/ieee80211_scan.c | 28 ++--
net/d80211/sta_info.c | 12 ++---
net/d80211/wme.c|8 ++-
4 files changed, 74 insertions(+), 72 deletions(-)
--- dscape.orig/net/d80211/ieee80211.c
+++ dscape/net/d80211/ieee80211.c
@@ -284,14 +284,14 @@ int ieee80211_get_hdrlen_from_skb(struct
EXPORT_SYMBOL(ieee80211_get_hdrlen_from_skb);
#ifdef CONFIG_D80211_LOWTX_FRAME_DUMP
-static void ieee80211_dump_frame(const char *ifname, const char *title,
+static void ieee80211_dump_frame(int hwindex, const char *title,
struct sk_buff *skb)
{
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb-data;
u16 fc;
int hdrlen;
- printk(KERN_DEBUG %s: %s (len=%d), ifname, title, skb-len);
+ printk(KERN_DEBUG wiphy%d: %s (len=%d), hwindex, title, skb-len);
if (skb-len 4) {
printk(\n);
return;
@@ -315,7 +315,7 @@ static void ieee80211_dump_frame(const c
printk(\n);
}
#else /* CONFIG_D80211_LOWTX_FRAME_DUMP */
-static inline void ieee80211_dump_frame(const char *ifname, const char *title,
+static inline void ieee80211_dump_frame(int hwindex, const char *title,
struct sk_buff *skb)
{
}
@@ -945,8 +945,8 @@ static void purge_old_ps_buffers(struct
spin_unlock_bh(local-sta_lock);
local-total_ps_buffered = total;
- printk(KERN_DEBUG %s: PS buffers full - purged %d frames\n,
- local-mdev-name, purged);
+ printk(KERN_DEBUG wiphy%d: PS buffers full - purged %d frames\n,
+ local-hw.index, purged);
}
@@ -1147,7 +1147,7 @@ static int __ieee80211_tx(struct ieee802
int ret, i;
if (skb) {
- ieee80211_dump_frame(local-mdev-name, TX to low-level
driver, skb);
+ ieee80211_dump_frame(local-hw.index, TX to low-level driver,
skb);
ret = local-ops-tx(local_to_hw(local), skb, control);
if (ret)
return IEEE80211_TX_AGAIN;
@@ -1174,7 +1174,7 @@ static int __ieee80211_tx(struct ieee802
~IEEE80211_TXCTL_RATE_CTRL_PROBE;
}
- ieee80211_dump_frame(local-mdev-name,
+ ieee80211_dump_frame(local-hw.index,
TX to low-level driver, skb);
ret = local-ops-tx(local_to_hw(local),
tx-u.tx.extra_frag[i],
@@ -1375,8 +1375,10 @@ static int ieee80211_master_start_xmit(s
}
if (unlikely(!odev)) {
#ifdef CONFIG_D80211_VERBOSE_DEBUG
- printk(KERN_DEBUG %s: Discarded packet with nonexistent
- originating device\n, dev-name);
+ struct ieee80211_local *local = dev-ieee80211_ptr;
+
+ printk(KERN_DEBUG wiphy%d: Discarded packet with nonexistent
+ originating device\n, local-hw.index);
#endif
dev_kfree_skb(skb);
return 0;
@@ -1764,8 +1766,8 @@ struct sk_buff * ieee80211_beacon_get(st
rate = rate_control_get_rate(local, local-mdev, skb, extra);
if (!rate) {
if (net_ratelimit()) {
- printk(KERN_DEBUG %s: ieee80211_beacon_get: no
rate
- found\n, local-mdev-name);
+ printk(KERN_DEBUG wiphy%d:
ieee80211_beacon_get: no rate
+ found\n, local-hw.index);
}
dev_kfree_skb(skb);
return NULL;
@@ -1977,10 +1979,11 @@ static void ieee80211_tx_timeout(struct
{
struct ieee80211_local *local = dev-ieee80211_ptr;
- printk(KERN_WARNING %s: resetting interface.\n, dev-name);
+ printk(KERN_WARNING wiphy%d: resetting interface.\n, local-hw.index);
if (local-ops-reset(local_to_hw(local)))
- printk(KERN_ERR %s: failed to reset interface.\n, dev-name);
+ printk(KERN_ERR wiphy%d: failed to reset interface.\n,
+ local-hw.index);
else
netif_wake_queue(dev);
}
@@ -3493,24 +3496,25 @@ static void ieee80211_rx_michael_mic_rep
/* TODO: verify that this is not triggered by fragmented
* frames (hw does not verify MIC for them). */
- printk(KERN_DEBUG %s: TKIP hwaccel reported Michael MIC
+ printk(KERN_DEBUG wiphy%d: TKIP hwaccel reported Michael MIC
failure from
d80211: a patch for standalone d80211 tarball
This patch should be enough to allow creation of standalone d80211 tarball (i.e. version of d80211 that could be compiled without patching the vanilla kernel) after invisible master interface patches. It is completely untested. Signed-off-by: Jiri Benc [EMAIL PROTECTED] --- net/d80211/ieee80211_i.h |4 1 files changed, 4 insertions(+) --- dscape.orig/net/d80211/ieee80211_i.h +++ dscape/net/d80211/ieee80211_i.h @@ -26,6 +26,10 @@ /* ieee80211.o internal definitions, etc. These are not included into * low-level drivers. */ +#define ieee80211_ptr ax25_ptr +#define register_invisible_netdevice register_netdevice +#define unregister_invisible_netdevice unregister_netdevice + #ifndef ETH_P_PAE #define ETH_P_PAE 0x888E /* Port Access Entity (IEEE 802.1X) */ #endif /* ETH_P_PAE */ - 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 6/6] d80211: fix rtnl locking in ieee80211_register_hw
rtnl locking in ieee80211_register_hw was racy. This patch fixes that.
Unfortunatelly, the creation of master interface has to be still protected
by rtnl lock as we need to protect against addition of a new virtual
interface.
Signed-off-by: Jiri Benc [EMAIL PROTECTED]
---
net/d80211/ieee80211.c |4 +---
1 files changed, 1 insertion(+), 3 deletions(-)
--- dscape.orig/net/d80211/ieee80211.c
+++ dscape/net/d80211/ieee80211.c
@@ -4540,12 +4540,10 @@ int ieee80211_register_hw(struct ieee802
result = register_invisible_netdevice(local-mdev);
if (result 0) {
- rtnl_unlock();
goto fail_dev;
}
result = ieee80211_init_rate_ctrl_alg(local, NULL);
- rtnl_unlock();
if (result 0) {
printk(KERN_DEBUG wiphy%d: Failed to initialize rate control
algorithm\n, local-hw.index);
@@ -4564,7 +4562,6 @@ int ieee80211_register_hw(struct ieee802
ieee80211_install_qdisc(local-mdev);
/* add one default STA interface */
- rtnl_lock();
result = ieee80211_if_add(local-mdev, wlan%d, 1, sta_dev);
if (result == 0)
ieee80211_if_set_type(sta_dev, IEEE80211_IF_TYPE_STA);
@@ -4581,6 +4578,7 @@ fail_wep:
fail_rate:
unregister_invisible_netdevice(local-mdev);
fail_dev:
+ rtnl_unlock();
sta_info_stop(local);
fail_sta_info:
ieee80211_dev_sysfs_del(local);
-
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 5/6] d80211: remove useless callbacks from wmaster
Invisible master interface doesn't need a lot of callbacks (actually, even
the previous visible one didn't need them but that's another story).
Signed-off-by: Jiri Benc [EMAIL PROTECTED]
---
net/d80211/ieee80211.c |4
net/d80211/ieee80211_i.h |1 -
net/d80211/ieee80211_ioctl.c | 22 --
3 files changed, 27 deletions(-)
--- dscape.orig/net/d80211/ieee80211.c
+++ dscape/net/d80211/ieee80211.c
@@ -4479,10 +4479,6 @@ struct ieee80211_hw *ieee80211_alloc_hw(
sta_info_init(local);
mdev-hard_start_xmit = ieee80211_master_start_xmit;
- mdev-wireless_handlers =
- (struct iw_handler_def *) ieee80211_iw_master_handler_def;
-mdev-do_ioctl = ieee80211_ioctl;
- mdev-change_mtu = ieee80211_change_mtu;
mdev-tx_timeout = ieee80211_tx_timeout;
mdev-get_stats = ieee80211_get_stats;
mdev-open = ieee80211_master_open;
--- dscape.orig/net/d80211/ieee80211_i.h
+++ dscape/net/d80211/ieee80211_i.h
@@ -622,7 +622,6 @@ struct net_device_stats *ieee80211_dev_s
/* ieee80211_ioctl.c */
int ieee80211_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
extern const struct iw_handler_def ieee80211_iw_handler_def;
-extern const struct iw_handler_def ieee80211_iw_master_handler_def;
/* Set hw encryption from ieee80211 */
int ieee80211_set_hw_encryption(struct net_device *dev,
--- dscape.orig/net/d80211/ieee80211_ioctl.c
+++ dscape/net/d80211/ieee80211_ioctl.c
@@ -3243,25 +3243,3 @@ const struct iw_handler_def ieee80211_iw
.private_args = (struct iw_priv_args *) ieee80211_ioctl_priv,
.get_wireless_stats = ieee80211_get_wireless_stats,
};
-
-/* Wireless handlers for master interface */
-
-static const iw_handler ieee80211_master_handler[] =
-{
- [SIOCGIWNAME - SIOCIWFIRST] = (iw_handler) ieee80211_ioctl_giwname,
- [SIOCSIWFREQ - SIOCIWFIRST] = (iw_handler) ieee80211_ioctl_siwfreq,
- [SIOCGIWFREQ - SIOCIWFIRST] = (iw_handler) ieee80211_ioctl_giwfreq,
- [SIOCGIWRANGE - SIOCIWFIRST] = (iw_handler) ieee80211_ioctl_giwrange,
- [SIOCSIWRTS - SIOCIWFIRST] = (iw_handler) ieee80211_ioctl_siwrts,
- [SIOCGIWRTS - SIOCIWFIRST] = (iw_handler) ieee80211_ioctl_giwrts,
- [SIOCSIWFRAG - SIOCIWFIRST] = (iw_handler) ieee80211_ioctl_siwfrag,
- [SIOCGIWFRAG - SIOCIWFIRST] = (iw_handler) ieee80211_ioctl_giwfrag,
- [SIOCSIWRETRY - SIOCIWFIRST] = (iw_handler) ieee80211_ioctl_siwretry,
- [SIOCGIWRETRY - SIOCIWFIRST] = (iw_handler) ieee80211_ioctl_giwretry,
-};
-
-const struct iw_handler_def ieee80211_iw_master_handler_def =
-{
- .num_standard = sizeof(ieee80211_master_handler) / sizeof(iw_handler),
- .standard = ieee80211_master_handler,
-};
-
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] PA Semi PWRficient Ethernet driver
Basic initalization, setup comments.
+static int pasemi_mac_open(struct net_device *dev)
+{
+ struct pasemi_mac *mac = netdev_priv(dev);
+ unsigned int flags;
+ int ret;
+
+ pr_debug(pasemi_mac_open\n);
dev_dbg() ?
+
+ /* enable rx section */
+ pci_write_config_dword(mac-dma_pdev, PAS_DMA_COM_RXCMD,
+PAS_DMA_COM_RXCMD_EN);
+
+ /* enable tx section */
+ pci_write_config_dword(mac-dma_pdev, PAS_DMA_COM_TXCMD,
+PAS_DMA_COM_TXCMD_EN);
+
+ flags = PAS_MAC_CFG_TXP_FCE | PAS_MAC_CFG_TXP_FPC(3) |
+ PAS_MAC_CFG_TXP_SL(3) | PAS_MAC_CFG_TXP_COB(0xf) |
+ PAS_MAC_CFG_TXP_TIFT(8) | PAS_MAC_CFG_TXP_TIFG(12);
+
+ pci_write_config_dword(mac-pdev, PAS_MAC_CFG_TXP, flags);
+
+ flags = PAS_MAC_CFG_PCFG_S1 | PAS_MAC_CFG_PCFG_PE |
+ PAS_MAC_CFG_PCFG_PR | PAS_MAC_CFG_PCFG_CE;
+
+ flags |= PAS_MAC_CFG_PCFG_TSR_1G | PAS_MAC_CFG_PCFG_SPD_1G;
+
+ pci_write_config_dword(mac-iob_pdev,
PAS_IOB_DMA_RXCH_CFG(mac-dma_rxch),
+PAS_IOB_DMA_RXCH_CFG_CNTTH(30));
+
+ pci_write_config_dword(mac-iob_pdev, PAS_IOB_DMA_COM_TIMEOUTCFG,
+PAS_IOB_DMA_COM_TIMEOUTCFG_TCNT(100));
+
+ pci_write_config_dword(mac-pdev, PAS_MAC_CFG_PCFG, flags);
+
+ pasemi_mac_setup_rx_resources(dev);
+ pasemi_mac_setup_tx_resources(dev);
+
+ pci_write_config_dword(mac-pdev, PAS_MAC_IPC_CHNL,
+PAS_MAC_IPC_CHNL_DCHNO(mac-dma_rxch) |
+PAS_MAC_IPC_CHNL_BCH(mac-dma_rxch));
+
+ /* enable rx if */
+ pci_write_config_dword(mac-dma_pdev,
+PAS_DMA_RXINT_RCMDSTA(mac-dma_if),
+PAS_DMA_RXINT_RCMDSTA_EN);
+
+ /* enable rx channel */
+ pci_write_config_dword(mac-dma_pdev,
+PAS_DMA_RXCHAN_CCMDSTA(mac-dma_rxch),
+PAS_DMA_RXCHAN_CCMDSTA_EN |
+PAS_DMA_RXCHAN_CCMDSTA_DU);
+
+ /* enable tx channel */
+ pci_write_config_dword(mac-dma_pdev,
+PAS_DMA_TXCHAN_TCMDSTA(mac-dma_txch),
+PAS_DMA_TXCHAN_TCMDSTA_EN);
+
+ pasemi_mac_replenish_rx_ring(dev);
+
+ netif_start_queue(dev);
+ netif_poll_enable(dev);
+
+ ret = request_irq(128 + mac-dma_txch, pasemi_mac_tx_intr,
+ IRQF_DISABLED, pasemi_mac tx, dev);
Shouldn't you get IRQ value from PCI config?
+ if (ret)
+ printk(request_irq of irq %d failed: %d\n,
+mac-dma_pdev-irq + mac-dma_txch, ret);
+
+ ret = request_irq(128 + 20 + mac-dma_rxch, pasemi_mac_rx_intr,
+ IRQF_DISABLED, pasemi_mac rx, dev);
+ if (ret)
+ printk(request_irq of irq %d failed: %d\n,
+mac-dma_pdev-irq + 20 + mac-dma_rxch, ret);
You need to return error code and unwind other request_irq.
+ return 0;
+}
+
+static int pasemi_mac_close(struct net_device *dev)
+{
+ struct pasemi_mac *mac = netdev_priv(dev);
+ unsigned int stat;
+
+ netif_stop_queue(dev);
+
+ /* Clean out any pending buffers */
+ pasemi_mac_clean_tx(mac);
+ pasemi_mac_clean_rx(mac, mac-rx-count);
+
+ /* Disable interface */
+ pci_write_config_dword(mac-dma_pdev,
+PAS_DMA_TXCHAN_TCMDSTA(mac-dma_txch),
+PAS_DMA_TXCHAN_TCMDSTA_ST);
+ pci_write_config_dword(mac-dma_pdev,
+ PAS_DMA_RXINT_RCMDSTA(mac-dma_if),
+ PAS_DMA_RXINT_RCMDSTA_ST);
+ pci_write_config_dword(mac-dma_pdev,
+ PAS_DMA_RXCHAN_CCMDSTA(mac-dma_rxch),
+ PAS_DMA_RXCHAN_CCMDSTA_ST);
+
+ do {
+ pci_read_config_dword(mac-dma_pdev,
+ PAS_DMA_TXCHAN_TCMDSTA(mac-dma_txch),
+ stat);
+ } while (stat PAS_DMA_TXCHAN_TCMDSTA_ACT);
+
+ do {
+ pci_read_config_dword(mac-dma_pdev,
+ PAS_DMA_RXCHAN_CCMDSTA(mac-dma_rxch),
+ stat);
+ } while (stat PAS_DMA_RXCHAN_CCMDSTA_ACT);
+
+ do {
+ pci_read_config_dword(mac-dma_pdev,
+ PAS_DMA_RXINT_RCMDSTA(mac-dma_if),
+ stat);
+ } while (stat PAS_DMA_RXINT_RCMDSTA_ACT);
+
+ /* Then, disable the channel. This must be done separately from
+ * stopping, since you can't disable when active.
+ */
+
+ pci_write_config_dword(mac-dma_pdev,
+PAS_DMA_TXCHAN_TCMDSTA(mac-dma_txch), 0);
+ pci_write_config_dword(mac-dma_pdev,
+PAS_DMA_RXCHAN_CCMDSTA(mac-dma_rxch), 0);
+
Re: [RFC PATCH 1/6] invisible network devices
On Mon, 29 Jan 2007 18:48:06 +0100 (CET) Jiri Benc [EMAIL PROTECTED] wrote: The d80211 stack needs a network interface (called 'wmaster') used for communication with the hardware (it has 802.11 qdisc attached which perform MAC level QoS). This interface is not intended for users and it confuses them. As a short time solution, this patch allows net_device to be registered as invisible. This means it is not in the dev name hash list, its ifindex is -1 and protocols are not notified about its registration/unregistration. Signed-off-by: Jiri Benc [EMAIL PROTECTED] Maybe code would be cleaner if you just could do: register_netdevice(mydev); cloak_netdevice(mydev); And cloak_netdevice() just removed the network device from the name table. I would rather keep it with a real ifindex and in the device list, so that if the interface is miss used or the device is referenced by other devices, we don't see unexpected surprises like oops. -- 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: bonding: bug in balance-alb mode (incorrect update-ARP-replie s)
Jay Vosburgh wrote: Well, I meant other traffic that causes the ARP replies to be generated (i.e., concurrent traffic with the system). No - there wasn't any concurrent network traffic. The system on which I've made the tcpdump had only the SSH-traffic to my box and no traffic to the system where the bond was running. There are some other issues with the rx hashtbl that have come up from my poking around, largely that it never, ever removes an entry from the table. After a sufficient number of different clients have A kind of aging would be hip. Is it easy for you to (shortly) describe the cases on which bonding tends to make update-storms or better: in which cases does it make a reply to the client? AFAIK it only does this, if packets from a client are comming on the wrong interface. I tried to analyse the problem but I don't find the needle in the hay-stack. - 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: d80211: a patch for standalone d80211 tarball
Hi, This patch should be enough to allow creation of standalone d80211 tarball (i.e. version of d80211 that could be compiled without patching the vanilla kernel) after invisible master interface patches. That looks very nice indeed, that saves me quite a big patch I usually apply to the rt2x00-cvs version of d80211. :) It is completely untested. I will put this patch into the rt2x00-cvs version of d80211 to see if it works. :) Thanks. Ivo P.S. I have some d80211 patches in testing that would add support for: - software rts - software sequence - tx_header_room fixes As soon as they are tested I'll send them to the list. :) - 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: d80211: a patch for standalone d80211 tarball
Hi, Jiri! On Mon, 2007-01-29 at 18:48 +0100, Jiri Benc wrote: +#define register_invisible_netdevice register_netdevice +#define unregister_invisible_netdevice unregister_netdevice Please use macros with arguments whenever possible. This way, incorrect macro invocations would be detected even if the original prototype is missing. Also, the macro name could be used without arguments for other purposes (variable, gcc attribute etc). Both cases are highly unlikely for the above macros, but please keep in mind that some aspiring programmers view the kernel as an example of good programming style. -- Regards, Pavel Roskin - 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
planned driver updates for 2.4.35
Hi David, As stated with the 2.4.34 announcement, I planned to perform a few updates in two network drivers for 2.4.35 : - e1000: the cards equipped with the not-so old 82546EB chips have completely disappeared from the earth surface, and people replacing hardware are experiencing trouble with the new chip (82546GB) which is not supported by the old driver. I know that Red Hat merged support for this chip in RHEL3 recently too (U8) by upgrading from v6 to v7. Jesse Brandeburg from Intel offered to update the driver to the more recent branch (7.3), which will make further maintenance easier for him. I personnally use 7.3 on my own kernels, so I just know that it works well for the NICs I'm used to find on servers, but for the rest, I'll have to rely on Intel people's support. - sk98lin: when Stephen decided to rewrite that driver from scratch because the one from Marvell's site has too many bugs, I thought he was exagerating, till the day I noticed NFS servers taking a lot of time to respond and DNS servers timing out because of UDP packets suddenly not leaving the host anymore. I recently encountered a worst case at a customer's with losses, duplicates and truncated packets. It's clear that the driver is too buggy. Each time I replaced the official driver with Stephen's backport and it definitely fixed the problems. I proposed Stephen to merge his work into 2.4, and he agreed, offering to update it once it gets in, which I'm fine with. This means I would start with skge-1.4 and sky2-0.5 which I could not get to fault on various intensive tests nor on the one which trigger sk98lin's bugs. Since those drivers support cards that are currently only supported by the out-of-tree driver from Marvell's site, no compatibility is lost and users can still use their old driver if they prefer it (as I did till I got those bugs). Aside that, I rejected a user's request for an update of the tg3 driver which does not support one recent chip in a notebook. I think that a notebook is not a big enough argument to touch this driver which works quite well IMHO. A notebook is clearly where he should use 2.6 by default, or take the time to download and install the out-of-tree code from broadcom's site if he absolutely wants 2.4. Maybe I'm wrong, but I have not tested the unofficial tg3 enough to have an opinion, and I don't want to break things that work just for this. I'd like to get your opinion on those updates before I open 2.4.35. I think that integrating them early is the best way to get more testing, since people often try the first and the latest versions only. Best regards, Willy - 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] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
Quick reality check here. In thinking about how best to go about this redirection of frames to the default router, based on Dave M.s input, I think that the best solution would be in ndisc_send_ns. What I was thinking was that in ndisc_send_ns, we already detect if a source address is optimistic and squash the transmission of the frame there. What if in addition to that supression, we also immediately update the neighbor cache entry for the requested host, to reflect the mac address of the default gateway. That way any dst cache lookups for hosts we don't know the true link layer address for will get redirected to the default gateway. Then any ICMP redirect messages from the router will fix those entires up for us. Later, when DAD completes, normal neighbour garbage collection and/or timeouts will sort out the neighbor cache entries for us. Or alternatively we could flush the cache entirely, or scan the cache for entires that match the lladdr of the default gateway and do a selective purge. I'm going to start implementing this, but I wanted to post it here to make sure I'm not missing anything really big on this idea. Thanks Regards Neil - 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
[RFC] Alternative hidden netwirk device interface
Change to allow register_netdevice() to be called with a blank name.
If name is blank, it is not put in name hash list, and doesn't
show up in /sys or /proc
Compile tested only...
---
net/core/dev.c | 56 +---
1 files changed, 33 insertions(+), 23 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index e660cb5..91f64e7 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -737,7 +737,7 @@ int dev_change_name(struct net_device *d
if (dev-flags IFF_UP)
return -EBUSY;
- if (!dev_valid_name(newname))
+ if (hlist_unhashed(dev-name_hlist) || !dev_valid_name(newname))
return -EINVAL;
if (strchr(newname, '%')) {
@@ -2108,6 +2108,10 @@ void dev_seq_stop(struct seq_file *seq,
static void dev_seq_printf_stats(struct seq_file *seq, struct net_device *dev)
{
+ /* hidden device */
+ if (hlist_unhashed(dev-name_hlist))
+ return;
+
if (dev-get_stats) {
struct net_device_stats *stats = dev-get_stats(dev);
@@ -2868,10 +2872,6 @@ static inline void net_set_todo(struct n
*
* Callers must hold the rtnl semaphore. You may want
* register_netdev() instead of this.
- *
- * BUGS:
- * The locking appears insufficient to guarantee two parallel registers
- * will not get the same name.
*/
int register_netdevice(struct net_device *dev)
@@ -2907,7 +2907,7 @@ #endif
}
}
- if (!dev_valid_name(dev-name)) {
+ if (dev-name[0] !dev_valid_name(dev-name)) {
ret = -EINVAL;
goto out;
}
@@ -2917,15 +2917,18 @@ #endif
dev-iflink = dev-ifindex;
/* Check for existence of name */
- head = dev_name_hash(dev-name);
- hlist_for_each(p, head) {
- struct net_device *d
- = hlist_entry(p, struct net_device, name_hlist);
- if (!strncmp(d-name, dev-name, IFNAMSIZ)) {
- ret = -EEXIST;
- goto out;
+ if (dev-name[0]) {
+ head = dev_name_hash(dev-name);
+ hlist_for_each(p, head) {
+ struct net_device *d
+ = hlist_entry(p, struct net_device, name_hlist);
+ if (!strncmp(d-name, dev-name, IFNAMSIZ)) {
+ ret = -EEXIST;
+ goto out;
+ }
}
- }
+ } else
+ head = NULL;
/* Fix illegal SG+CSUM combinations. */
if ((dev-features NETIF_F_SG)
@@ -2945,14 +2948,14 @@ #endif
if (dev-features NETIF_F_UFO) {
if (!(dev-features NETIF_F_HW_CSUM)) {
printk(KERN_ERR %s: Dropping NETIF_F_UFO since no
- NETIF_F_HW_CSUM feature.\n,
- dev-name);
+ NETIF_F_HW_CSUM feature.\n,
+ dev-name);
dev-features = ~NETIF_F_UFO;
}
if (!(dev-features NETIF_F_SG)) {
printk(KERN_ERR %s: Dropping NETIF_F_UFO since no
- NETIF_F_SG feature.\n,
- dev-name);
+ NETIF_F_SG feature.\n,
+ dev-name);
dev-features = ~NETIF_F_UFO;
}
}
@@ -2965,8 +2968,7 @@ #endif
if (!dev-rebuild_header)
dev-rebuild_header = default_rebuild_header;
- ret = netdev_register_sysfs(dev);
- if (ret)
+ if (head (ret = netdev_register_sysfs(dev)))
goto out;
dev-reg_state = NETREG_REGISTERED;
@@ -2982,7 +2984,12 @@ #endif
write_lock_bh(dev_base_lock);
*dev_tail = dev;
dev_tail = dev-next;
- hlist_add_head(dev-name_hlist, head);
+
+ if (head)
+ hlist_add_head(dev-name_hlist, head);
+ else
+ INIT_HLIST_NODE(dev-name_hlist);
+
hlist_add_head(dev-index_hlist, dev_index_hash(dev-ifindex));
dev_hold(dev);
write_unlock_bh(dev_base_lock);
@@ -3013,8 +3020,10 @@ int register_netdev(struct net_device *d
{
int err;
- rtnl_lock();
+ if (!dev-name[0])
+ return -EINVAL;
+ rtnl_lock();
/*
* If the name is a format string the caller wants us to do a
* name allocation.
@@ -3271,7 +3280,8 @@ int unregister_netdevice(struct net_devi
for (dp = dev_base; (d = *dp) != NULL; dp = d-next) {
if (d == dev) {
write_lock_bh(dev_base_lock);
- hlist_del(dev-name_hlist);
+ if (!hlist_unhashed(dev-name_hlist))
Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
In article [EMAIL PROTECTED] (at Mon, 29 Jan 2007 16:30:13 -0500), Neil Horman [EMAIL PROTECTED] says: Quick reality check here. In thinking about how best to go about this redirection of frames to the default router, based on Dave M.s input, I think that the best solution would be in ndisc_send_ns. What I was thinking was that in ndisc_send_ns, we already detect if a source address is optimistic and squash the transmission of the frame there. What if in addition to that supression, we : Well...I think it is okay if sending NS is deferred (or omit) in ndisc_send_ns() (or in ndisc_solicit(), probably) if the source is optimistic address, but... I'm not sure so far if it is appropriate from design POV. The ndisc_send_ns() nor ndisc_solicit() is not about our current neigh state machine, at all. I do not think we should copy neighbor information from (one of) default routers, but use temporary neigh entry (or neigh in new state) for such datagrams in stead. We should aware that: 1) default router's link-layer address may change. 2) we may have more than one default routers. 3) the default router's link-layer may be invalidated. Anyway, I'm start thinking about CONFIG_IPV6_OPTIMISTIC_DAD to make sure the new code path will not break anything else... --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
[PATCH -FIX] e100: fix irq leak on suspend/resume
e100: fix irq leak on suspend/resume
From: Frederik Deweerdt [EMAIL PROTECTED]
The e100_resume() function should be calling netif_device_detach and
free_irq. This fixes multiple irq's being allocated after resume.
Signed-off-by: Frederik Deweerdt [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e100.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index c2ae2a2..3208dac 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -2725,6 +2725,7 @@ static int e100_suspend(struct pci_dev *pdev,
pm_message_t state)
del_timer_sync(nic-watchdog);
netif_carrier_off(nic-netdev);
+ netif_device_detach(netdev);
pci_save_state(pdev);
if ((nic-flags wol_magic) | e100_asf(nic)) {
@@ -2736,6 +2737,7 @@ static int e100_suspend(struct pci_dev *pdev,
pm_message_t state)
}
pci_disable_device(pdev);
+ free_irq(pdev-irq, netdev);
pci_set_power_state(pdev, PCI_D3hot);
return 0;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PA Semi PWRficient Ethernet driver
Olof Johansson [EMAIL PROTECTED] :
Driver for the PA Semi PWRficient on-chip Ethernet (1/10G)
Basic enablement, will be complemented with performance enhancements
over time. PHY support will be added as well.
- The driver does not contain a single SMP locking instruction but
http://www.pasemi.com claims the platform to be multicore.
Is the driver really designed to be lockless ?
- Is there really no other choice than constantly accessing the
registers of the device through pci_write_config_dword() ?
No PCI BAR remappable area ?
- Is there a volunteer to maintain the driver ? If so the MAINTAINERS
file should be updated (hint, hint).
- No known public documentation for the hardware ?
Inlined remarks below.
[...]
Index: merge/drivers/net/pasemi_mac.c
===
--- /dev/null
+++ merge/drivers/net/pasemi_mac.c
@@ -0,0 +1,797 @@
+/*
+ * Copyright (C) 2006-2007 PA Semi, Inc
+ *
+ * Driver for the PA Semi PWRficient onchip 1G/10G Ethernet MACs
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include linux/pci.h
+#include linux/interrupt.h
+#include linux/dmaengine.h
+#include linux/delay.h
+#include linux/netdevice.h
+#include linux/etherdevice.h
+#include asm/dma-mapping.h
+#include linux/in.h
+#include linux/skbuff.h
+
+#include linux/ip.h
+#include linux/tcp.h
+#include net/checksum.h
+
+#include pasemi_mac.h
+
+#define INITIAL_RX_RING_SIZE 512
+#define INITIAL_TX_RING_SIZE 512
+
+#define BUF_SIZE 2048
Is there a specific reason for this rather unusual size ?
+
+#define PAS_DMA_MAX_IF 40
+#define PAS_DMA_MAX_RXCH 8
+#define PAS_DMA_MAX_TXCH 8
+
+/* XXXOJN these should come out of the device tree some day */
+#define PAS_DMA_CAP_BASE 0xe00d0040
+#define PAS_DMA_CAP_SIZE 0x100
+#define PAS_DMA_COM_BASE 0xe00d0100
+#define PAS_DMA_COM_SIZE 0x100
+
+static irqreturn_t pasemi_mac_tx_intr(int, void *);
+static irqreturn_t pasemi_mac_rx_intr(int, void *);
+static int pasemi_mac_clean_tx(struct pasemi_mac *mac);
+static int pasemi_mac_clean_rx(struct pasemi_mac *mac, int limit);
Reorder and remove the forward declarations ?
+
+static struct pasdma_status *dma_status;
+
+static int pasemi_set_mac_addr(struct pasemi_mac *mac)
+{
+ struct pci_dev *pdev = mac-pdev;
+ struct device_node *dn = pci_device_to_OF_node(pdev);
+ const u8 *maddr;
+ u8 addr[6];
+
+ if (!dn) {
+ dev_dbg(pdev-dev,
+ No device node for mac, not configuring\n);
+ return -ENOENT;
+ }
+
+ maddr = get_property(dn, mac-address, NULL);
+ if (maddr == NULL) {
+ dev_warn(pdev-dev,
+ no mac address in device tree, not configuring\n);
+ return -ENOENT;
+ }
+
+ if (sscanf(maddr, %hhx:%hhx:%hhx:%hhx:%hhx:%hhx, addr[0],
+addr[1], addr[2], addr[3], addr[4], addr[5]) != 6) {
+ dev_warn(pdev-dev,
+ can't parse mac address, not configuring\n);
+ return -EINVAL;
+ }
+
+ memcpy(mac-mac_addr, addr, sizeof(addr));
Add a check for is_valid_ether_addr() ?
+ return 0;
+}
+
+static void pasemi_mac_setup_rx_resources(struct net_device *dev)
+{
+ struct pasemi_mac_rxring *ring;
+ struct pasemi_mac *mac = netdev_priv(dev);
+ int chan_id = mac-dma_rxch;
+
+ ring = kzalloc(sizeof(*ring), GFP_KERNEL);
k*alloc can fail. Please check !ring.
+
+ ring-count = INITIAL_RX_RING_SIZE;
+
+ ring-desc_info = kzalloc(sizeof(struct pasemi_mac_buffer)*ring-count,
+ GFP_KERNEL);
+
+ /* Allocate descriptors */
+ ring-desc = (void *)__get_free_pages(GFP_KERNEL,
+ get_order(ring-count *
+ sizeof(struct pas_dma_xct_descr)));
+ ring-dma = virt_to_phys(ring-desc);
+ memset(ring-desc, 0, ring-count * sizeof(struct pas_dma_xct_descr));
+
+ ring-buffers = (void *)__get_free_pages(GFP_KERNEL,
+ get_order(ring-count * sizeof(u64)));
+ ring-buf_dma = virt_to_phys(ring-buffers);
+ memset(ring-buffers, 0, ring-count * sizeof(u64));
Use
Re: sky2 problems on Intel Mac Mini
On Mon, 29 Jan 2007 23:57:32 + Chris Lightfoot [EMAIL PROTECTED] wrote: [ please cc: me on any reply ] I'm seeing lots of problems with the sky2 driver on Mac Minis. Based on the suggestions in, http://www.mail-archive.com/netdev@vger.kernel.org/msg28221.html I am running stock 2.6.19 + the patches from the mactel-linux.org site to get the kernel booting on the Apple hardware; none of these touches the sky2 code. The module is installed with disable_msi=1 and idle_timeout=10; the chip version is, Yukon-EC (0xb6) rev 2 The crashes we're seeing at the moment show (with debug=16) lots and lots of transmits being queued up and never being completed, even with the timeout switched on. For instance, (this is on a machine running NFS root and vlans) Is this NFS over UDP? [ lots of normal activity alternating tx queued / tx done ] Jan 29 21:03:22 yeti kernel: eth0: tx queued, slot 65, len 150 Jan 29 21:03:22 yeti kernel: sky2 eth0: rx slot 106 status 0x9e2100 len 154 Jan 29 21:03:22 yeti kernel: eth0: tx done 66 Jan 29 21:03:22 yeti kernel: eth0: tx queued, slot 67, len 150 Jan 29 21:03:22 yeti kernel: sky2 eth0: rx slot 107 status 0x9e2100 len 154 Jan 29 21:03:22 yeti kernel: eth0: tx done 68 Jan 29 21:03:22 yeti kernel: eth0: tx queued, slot 69, len 150 Jan 29 21:03:22 yeti kernel: sky2 eth0: rx slot 108 status 0x9e2100 len 154 Jan 29 21:03:22 yeti kernel: eth0: tx done 70 Jan 29 21:03:22 yeti kernel: eth0: tx queued, slot 71, len 89 Jan 29 21:03:22 yeti kernel: eth0: tx queued, slot 73, len 1090 Jan 29 21:03:22 yeti kernel: eth0: tx queued, slot 75, len 1514 Jan 29 21:03:22 yeti kernel: eth0: tx queued, slot 79, len 90 Jan 29 21:03:22 yeti kernel: eth0: tx queued, slot 81, len 1514 Jan 29 21:03:22 yeti kernel: eth0: tx queued, slot 84, len 1090 Jan 29 21:03:23 yeti kernel: eth0: tx queued, slot 86, len 98 Jan 29 21:03:23 yeti kernel: eth0: tx queued, slot 88, len 1514 Jan 29 21:03:23 yeti kernel: eth0: tx queued, slot 91, len 1090 Jan 29 21:03:23 yeti kernel: eth0: tx queued, slot 93, len 54 Jan 29 21:03:23 yeti kernel: eth0: tx queued, slot 94, len 66 Jan 29 21:03:24 yeti kernel: eth0: tx queued, slot 95, len 54 Jan 29 21:03:24 yeti kernel: eth0: tx queued, slot 96, len 66 Jan 29 21:03:24 yeti kernel: eth0: tx queued, slot 97, len 98 [ ... and so on for a total of 109 tx queued with no tx done, after which our watchdog rebooted the machine ] -- though we've also seen, e.g., (no NFS root, no vlans) Jan 28 19:32:16 t1 kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 28 19:32:16 t1 kernel: sky2 eth0: tx timeout Jan 28 19:32:16 t1 kernel: sky2 eth0: transmit ring 115 .. 92 report=115 done=115 Jan 28 19:32:16 t1 kernel: sky2 hardware hung? flushing Jan 28 19:32:25 t1 kernel: BUG: soft lockup detected on CPU#0! Jan 28 19:32:25 t1 kernel: [c015495a] softlockup_tick+0xba/0xe0 Jan 28 19:32:25 t1 kernel: [c01327e9] update_process_times+0x39/0x90 Jan 28 19:32:25 t1 kernel: [c0117337] smp_apic_timer_interrupt+0x97/0xc0 Jan 28 19:32:25 t1 kernel: [c0103eab] apic_timer_interrupt+0x1f/0x24 Jan 28 19:32:25 t1 kernel: [c0445107] _spin_lock_irqsave+0x67/0x80 Jan 28 19:32:25 t1 kernel: [c0445136] _spin_lock_bh+0x6/0x20 Jan 28 19:32:25 t1 kernel: [c0302f40] sky2_tx_clean+0x20/0x70 Jan 28 19:32:25 t1 kernel: [c0303904] sky2_tx_timeout+0x144/0x1b0 Jan 28 19:32:25 t1 kernel: [c03da1c0] dev_watchdog+0x0/0xe0 Jan 28 19:32:25 t1 kernel: [c03da28e] dev_watchdog+0xce/0xe0 Jan 28 19:32:25 t1 kernel: [c0132916] run_timer_softirq+0xc6/0x1c0 Jan 28 19:32:25 t1 kernel: [c0120c80] scheduler_tick+0xb0/0x3a0 Jan 28 19:32:25 t1 kernel: [c012d1ea] __do_softirq+0xca/0xf0 Jan 28 19:32:25 t1 kernel: [c012d245] do_softirq+0x35/0x40 Jan 28 19:32:25 t1 kernel: [c012d295] irq_exit+0x45/0x50 Jan 28 19:32:25 t1 kernel: [c011733c] smp_apic_timer_interrupt+0x9c/0xc0 Jan 28 19:32:25 t1 kernel: [c0103eab] apic_timer_interrupt+0x1f/0x24 Jan 28 19:32:25 t1 kernel: [c0101332] mwait_idle_with_hints+0x32/0x40 Jan 28 19:32:25 t1 kernel: [c0101370] mwait_idle+0x30/0x40 Jan 28 19:32:25 t1 kernel: [c0101144] cpu_idle+0x94/0xe0 Jan 28 19:32:25 t1 kernel: [c0592a16] start_kernel+0x1c6/0x230 Jan 28 19:32:25 t1 kernel: [c0592360] unknown_bootoption+0x0/0x1e0 Jan 28 19:32:25 t1 kernel: === -- I assume this is just the same problem exhibiting on a kernel with soft lockups detection enabled? Hopefully I should be able to actually log into one of these machines over an alternate connection next time the problem recurs, at which point I should be able to get ethtool -d output. Anything else I should do at that point? Any suggestions for what to do next to chase this problem down? I haven't yet tried the sk98lin driver on this hardware; is that still worth doing? Are there any useful tests we should try? Unfortunately, though these crashes happen pretty frequently (several times
sky2 problems on Intel Mac Mini
[ please cc: me on any reply ] I'm seeing lots of problems with the sky2 driver on Mac Minis. Based on the suggestions in, http://www.mail-archive.com/netdev@vger.kernel.org/msg28221.html I am running stock 2.6.19 + the patches from the mactel-linux.org site to get the kernel booting on the Apple hardware; none of these touches the sky2 code. The module is installed with disable_msi=1 and idle_timeout=10; the chip version is, Yukon-EC (0xb6) rev 2 The crashes we're seeing at the moment show (with debug=16) lots and lots of transmits being queued up and never being completed, even with the timeout switched on. For instance, (this is on a machine running NFS root and vlans) [ lots of normal activity alternating tx queued / tx done ] Jan 29 21:03:22 yeti kernel: eth0: tx queued, slot 65, len 150 Jan 29 21:03:22 yeti kernel: sky2 eth0: rx slot 106 status 0x9e2100 len 154 Jan 29 21:03:22 yeti kernel: eth0: tx done 66 Jan 29 21:03:22 yeti kernel: eth0: tx queued, slot 67, len 150 Jan 29 21:03:22 yeti kernel: sky2 eth0: rx slot 107 status 0x9e2100 len 154 Jan 29 21:03:22 yeti kernel: eth0: tx done 68 Jan 29 21:03:22 yeti kernel: eth0: tx queued, slot 69, len 150 Jan 29 21:03:22 yeti kernel: sky2 eth0: rx slot 108 status 0x9e2100 len 154 Jan 29 21:03:22 yeti kernel: eth0: tx done 70 Jan 29 21:03:22 yeti kernel: eth0: tx queued, slot 71, len 89 Jan 29 21:03:22 yeti kernel: eth0: tx queued, slot 73, len 1090 Jan 29 21:03:22 yeti kernel: eth0: tx queued, slot 75, len 1514 Jan 29 21:03:22 yeti kernel: eth0: tx queued, slot 79, len 90 Jan 29 21:03:22 yeti kernel: eth0: tx queued, slot 81, len 1514 Jan 29 21:03:22 yeti kernel: eth0: tx queued, slot 84, len 1090 Jan 29 21:03:23 yeti kernel: eth0: tx queued, slot 86, len 98 Jan 29 21:03:23 yeti kernel: eth0: tx queued, slot 88, len 1514 Jan 29 21:03:23 yeti kernel: eth0: tx queued, slot 91, len 1090 Jan 29 21:03:23 yeti kernel: eth0: tx queued, slot 93, len 54 Jan 29 21:03:23 yeti kernel: eth0: tx queued, slot 94, len 66 Jan 29 21:03:24 yeti kernel: eth0: tx queued, slot 95, len 54 Jan 29 21:03:24 yeti kernel: eth0: tx queued, slot 96, len 66 Jan 29 21:03:24 yeti kernel: eth0: tx queued, slot 97, len 98 [ ... and so on for a total of 109 tx queued with no tx done, after which our watchdog rebooted the machine ] -- though we've also seen, e.g., (no NFS root, no vlans) Jan 28 19:32:16 t1 kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 28 19:32:16 t1 kernel: sky2 eth0: tx timeout Jan 28 19:32:16 t1 kernel: sky2 eth0: transmit ring 115 .. 92 report=115 done=115 Jan 28 19:32:16 t1 kernel: sky2 hardware hung? flushing Jan 28 19:32:25 t1 kernel: BUG: soft lockup detected on CPU#0! Jan 28 19:32:25 t1 kernel: [c015495a] softlockup_tick+0xba/0xe0 Jan 28 19:32:25 t1 kernel: [c01327e9] update_process_times+0x39/0x90 Jan 28 19:32:25 t1 kernel: [c0117337] smp_apic_timer_interrupt+0x97/0xc0 Jan 28 19:32:25 t1 kernel: [c0103eab] apic_timer_interrupt+0x1f/0x24 Jan 28 19:32:25 t1 kernel: [c0445107] _spin_lock_irqsave+0x67/0x80 Jan 28 19:32:25 t1 kernel: [c0445136] _spin_lock_bh+0x6/0x20 Jan 28 19:32:25 t1 kernel: [c0302f40] sky2_tx_clean+0x20/0x70 Jan 28 19:32:25 t1 kernel: [c0303904] sky2_tx_timeout+0x144/0x1b0 Jan 28 19:32:25 t1 kernel: [c03da1c0] dev_watchdog+0x0/0xe0 Jan 28 19:32:25 t1 kernel: [c03da28e] dev_watchdog+0xce/0xe0 Jan 28 19:32:25 t1 kernel: [c0132916] run_timer_softirq+0xc6/0x1c0 Jan 28 19:32:25 t1 kernel: [c0120c80] scheduler_tick+0xb0/0x3a0 Jan 28 19:32:25 t1 kernel: [c012d1ea] __do_softirq+0xca/0xf0 Jan 28 19:32:25 t1 kernel: [c012d245] do_softirq+0x35/0x40 Jan 28 19:32:25 t1 kernel: [c012d295] irq_exit+0x45/0x50 Jan 28 19:32:25 t1 kernel: [c011733c] smp_apic_timer_interrupt+0x9c/0xc0 Jan 28 19:32:25 t1 kernel: [c0103eab] apic_timer_interrupt+0x1f/0x24 Jan 28 19:32:25 t1 kernel: [c0101332] mwait_idle_with_hints+0x32/0x40 Jan 28 19:32:25 t1 kernel: [c0101370] mwait_idle+0x30/0x40 Jan 28 19:32:25 t1 kernel: [c0101144] cpu_idle+0x94/0xe0 Jan 28 19:32:25 t1 kernel: [c0592a16] start_kernel+0x1c6/0x230 Jan 28 19:32:25 t1 kernel: [c0592360] unknown_bootoption+0x0/0x1e0 Jan 28 19:32:25 t1 kernel: === -- I assume this is just the same problem exhibiting on a kernel with soft lockups detection enabled? Hopefully I should be able to actually log into one of these machines over an alternate connection next time the problem recurs, at which point I should be able to get ethtool -d output. Anything else I should do at that point? Any suggestions for what to do next to chase this problem down? I haven't yet tried the sk98lin driver on this hardware; is that still worth doing? Are there any useful tests we should try? Unfortunately, though these crashes happen pretty frequently (several times per day typically), I don't have a test case to reproduce one; however, if it'd be useful, I can probably get a pcap trace of the period immediately before the interface falls over using port
[PATCH] sky2: revert IRQ dance on suspend/resume
Let's just backout the IRQ hack, and for those crap machines
(like some Sony VAIO's) can just disable MSI with the module
parameter.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED](none)
---
drivers/net/sky2.c | 25 -
1 files changed, 0 insertions(+), 25 deletions(-)
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index a2e804d..822dd0b 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -3639,29 +3639,6 @@ static int sky2_resume(struct pci_dev *p
out:
return err;
}
-
-/* BIOS resume runs after device (it's a bug in PM)
- * as a temporary workaround on suspend/resume leave MSI disabled
- */
-static int sky2_suspend_late(struct pci_dev *pdev, pm_message_t state)
-{
- struct sky2_hw *hw = pci_get_drvdata(pdev);
-
- free_irq(pdev-irq, hw);
- if (hw-msi) {
- pci_disable_msi(pdev);
- hw-msi = 0;
- }
- return 0;
-}
-
-static int sky2_resume_early(struct pci_dev *pdev)
-{
- struct sky2_hw *hw = pci_get_drvdata(pdev);
- struct net_device *dev = hw-dev[0];
-
- return request_irq(pdev-irq, sky2_intr, IRQF_SHARED, dev-name, hw);
-}
#endif
static struct pci_driver sky2_driver = {
@@ -3672,8 +3649,6 @@ static struct pci_driver sky2_driver = {
#ifdef CONFIG_PM
.suspend = sky2_suspend,
.resume = sky2_resume,
- .suspend_late = sky2_suspend_late,
- .resume_early = sky2_resume_early,
#endif
};
--
1.4.1
-
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] sky2: revert IRQ dance on suspend/resume
On Mon, 29 Jan 2007, Stephen Hemminger wrote: Signed-off-by: Stephen Hemminger [EMAIL PROTECTED](none) Mind if I fix your sign-off? ;) Linus - 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] sky2: revert IRQ dance on suspend/resume
On Mon, 29 Jan 2007 16:43:04 -0800 (PST) Linus Torvalds [EMAIL PROTECTED] wrote: On Mon, 29 Jan 2007, Stephen Hemminger wrote: Signed-off-by: Stephen Hemminger [EMAIL PROTECTED](none) Mind if I fix your sign-off? ;) Linus Sorry, that was the test machine... -- 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: [PATCH] PA Semi PWRficient Ethernet driver
On Mon, Jan 29, 2007 at 10:22:33AM -0800, Stephen Hemminger wrote:
Basic initalization, setup comments.
Thanks, fixes have been incorporated and will be reposted. Most of them
was obviously just my lack of diligence. See however the two below.
+static irqreturn_t pasemi_mac_tx_intr(int irq, void *data)
+{
+ struct net_device *dev = data;
+ struct pasemi_mac *mac = netdev_priv(dev);
+ unsigned int reg;
+
+ pasemi_mac_clean_tx(mac);
+
+ reg = PAS_IOB_DMA_TXCH_RESET_PINTC | PAS_IOB_DMA_TXCH_RESET_SINTC;
+ if (*mac-tx_status PAS_STATUS_TIMER)
+ reg |= PAS_IOB_DMA_TXCH_RESET_TINTC;
+
+ pci_write_config_dword(mac-iob_pdev,
PAS_IOB_DMA_TXCH_RESET(mac-dma_txch),
+ reg);
+
+ return IRQ_HANDLED;
+}
To do shared IRQ's properly you need to check to see if
this is your device IRQ or not. Maybe reading config value?
Right now it's guaranteed that the interrupts will not be shared. They're
fixed for the on-chip devices, and no other driver should be binding to
the same channels (and thus irqs).
If it changes in the future, the driver would need other rework as well.
+
+static struct pci_driver pasemi_mac_driver = {
+ .name = pasemi_mac,
+ .id_table = pasemi_mac_pci_tbl,
+ .probe = pasemi_mac_probe,
Don't you need a remove routine?
No hotplug support at this time, so I didn't see any use in providing one.
-Olof
-
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] PA Semi PWRficient Ethernet driver
Hi,
Thanks for the comments. In general I have applied them, with some specific
comments below.
I'll repost a new version of the driver based on this and other feedback
later tonight.
On Mon, Jan 29, 2007 at 11:35:06PM +0100, Francois Romieu wrote:
Olof Johansson [EMAIL PROTECTED] :
Driver for the PA Semi PWRficient on-chip Ethernet (1/10G)
Basic enablement, will be complemented with performance enhancements
over time. PHY support will be added as well.
- The driver does not contain a single SMP locking instruction but
http://www.pasemi.com claims the platform to be multicore.
Is the driver really designed to be lockless ?
Unless I misunderstood something, NAPI drivers that don't set NETIF_F_LLTX
will have all locking taken care of by higher layers, no?
- Is there really no other choice than constantly accessing the
registers of the device through pci_write_config_dword() ?
No PCI BAR remappable area ?
Maybe a bit of introduction could be useful (also regarding the
pci_map/alloc comments below).
Our devices are on-chip, and while they're not on a PCI(e) bus internally,
they do have config headers and will show up as devices on a pseudo-bus
(the root one, in fact).
Also, while the driver could go through the IOMMU layers, there's no
real use in doing so at this time.
When it comes to register access -- it would probably make sense to
remap them separately and use normal accessors instead of going through
the quite heavyweight PCI config accessors. I used them right now for
convenience.
As I already mentioned, there's not been a whole lot of performance work
done on this driver yet; I expect to address this when I get started
on that.
- Is there a volunteer to maintain the driver ? If so the MAINTAINERS
file should be updated (hint, hint).
Yep, forgot to include it.
- No known public documentation for the hardware ?
Not at this time, but the driver will be actively maintained so it
shouldn't be an issue.
Inlined remarks below.
Comments to some of them below.
+#define BUF_SIZE 2048
Is there a specific reason for this rather unusual size ?
A nice and round and large enough number. But no, no real reason. Fixed.
(And yes, large MTU support is also on the todo list. :-)
+ ring-buffers = (void *)__get_free_pages(GFP_KERNEL,
+get_order(ring-count * sizeof(u64)));
+ ring-buf_dma = virt_to_phys(ring-buffers);
+ memset(ring-buffers, 0, ring-count * sizeof(u64));
Use pci_alloc_consistent() ?
Nope, for reasons above.
+static noinline void pasemi_mac_free_resources(struct net_device *dev)
+{
+ struct pasemi_mac *mac = netdev_priv(dev);
+ int i;
unsigned int is supposed to save some cycles on ppc.
Who told you that? That's not true.
Still, there's no need for the iterator to be signed.
+ if (ret)
+ printk(request_irq of irq %d failed: %d\n,
+ mac-dma_pdev-irq + mac-dma_txch, ret);
Missing KERN_XYZ.
Changed all the printk's to be dev_*() instead based on Stephen's comments.
+static void pasemi_mac_set_rx_mode(struct net_device *dev)
+{
+ struct pasemi_mac *mac = netdev_priv(dev);
+ unsigned int flags;
+
+ return;
Huh ?
Yeah, forgot it there from debugging. Can't even remember why I added
it and I obviously missed it when going through before posting.
+
+ for (i = start; i start+mac-rx-count count limit; i++) {
^^^
I would not protest against a few parenthesis here and there.
+ rmb();
+ mb();
rmb() _and_ mb() ?
Btw a scroll of ancient incantation is available in
Documentation/memory-barriers.txt btw.
Not sure why they were still left in there. Only rmb is needed. Same
for the barrier at the bottom of the loop.
+static int __devinit
+pasemi_mac_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
+{
[..]
+ /* The dma status structure is located in the I/O bridge, and
+* is cache coherent.
+*/
+ if (!dma_status)
+ /* XXXOJN This should come from the device tree */
+ dma_status = __ioremap(0xfd80, 0x1000, 0);
Is this address really set in stone or can it be retrieved after some
pci_get_device(...) practice ?
As the comment says -- one day it should come out of the device tree. It's
a well-known and not dynamic address on the current chips; but it might be
located somewhere else on future products.
+ mac-rx_status = dma_status-rx_sta[mac-dma_rxch];
+ mac-tx_status = dma_status-tx_sta[mac-dma_txch];
Addresses returned from ioremap are not guaranteed to be dereferencable
like that.
That's why I'm using __ioremap instead, to get a cacheable regular area
to just reference.
Is there another preferred method of doing this? Note that it is a
cache-coherent status area, so regular ioremap() is not the solution.
+ { PCI_DEVICE(0x1959, 0xa005) },
+ { PCI_DEVICE(0x1959,
[PATCH] [v2]PA Semi PWRficient Ethernet driver
Driver for the PA Semi PWRficient on-chip Ethernet (1/10G)
Basic enablement, will be complemented with performance enhancements
over time. PHY support will be added as well.
This patch still uses numerical PCI IDs, they will be replaced when the
pci_ids.h change goes in, together with other currently pending drivers.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
---
This version contains changes based on comments from Stephen Hemminger
and Francois Romieu.
Index: merge/drivers/net/Kconfig
===
--- merge.orig/drivers/net/Kconfig
+++ merge/drivers/net/Kconfig
@@ -2348,6 +2348,13 @@ config QLA3XXX
To compile this driver as a module, choose M here: the module
will be called qla3xxx.
+config PASEMI_MAC
+ tristate PA Semi 1/10Gbit MAC
+ depends on PPC64 PCI
+ help
+ This driver supports the on-chip 1/10Gbit Ethernet controller on
+ PA Semi's PWRficient line of chips.
+
endmenu
#
Index: merge/drivers/net/Makefile
===
--- merge.orig/drivers/net/Makefile
+++ merge/drivers/net/Makefile
@@ -196,6 +196,7 @@ obj-$(CONFIG_SMC91X) += smc91x.o
obj-$(CONFIG_SMC911X) += smc911x.o
obj-$(CONFIG_DM9000) += dm9000.o
obj-$(CONFIG_FEC_8XX) += fec_8xx/
+obj-$(CONFIG_PASEMI_MAC) += pasemi_mac.o
obj-$(CONFIG_MACB) += macb.o
Index: merge/drivers/net/pasemi_mac.c
===
--- /dev/null
+++ merge/drivers/net/pasemi_mac.c
@@ -0,0 +1,875 @@
+/*
+ * Copyright (C) 2006-2007 PA Semi, Inc
+ *
+ * Driver for the PA Semi PWRficient onchip 1G/10G Ethernet MACs
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include linux/pci.h
+#include linux/interrupt.h
+#include linux/dmaengine.h
+#include linux/delay.h
+#include linux/netdevice.h
+#include linux/etherdevice.h
+#include asm/dma-mapping.h
+#include linux/in.h
+#include linux/skbuff.h
+
+#include linux/ip.h
+#include linux/tcp.h
+#include net/checksum.h
+
+#include pasemi_mac.h
+
+#define INITIAL_RX_RING_SIZE 512
+#define INITIAL_TX_RING_SIZE 512
+
+#define BUF_SIZE 1646 /* 1500 MTU + ETH_HLEN + VLAN_HLEN + 2 64B cachelines */
+
+#define PAS_DMA_MAX_IF 40
+#define PAS_DMA_MAX_RXCH 8
+#define PAS_DMA_MAX_TXCH 8
+
+/* XXXOJN these should come out of the device tree some day */
+#define PAS_DMA_CAP_BASE 0xe00d0040
+#define PAS_DMA_CAP_SIZE 0x100
+#define PAS_DMA_COM_BASE 0xe00d0100
+#define PAS_DMA_COM_SIZE 0x100
+
+static struct pasdma_status *dma_status;
+
+static int pasemi_set_mac_addr(struct pasemi_mac *mac)
+{
+ struct pci_dev *pdev = mac-pdev;
+ struct device_node *dn = pci_device_to_OF_node(pdev);
+ const u8 *maddr;
+ u8 addr[6];
+
+ if (!dn) {
+ dev_dbg(pdev-dev,
+ No device node for mac, not configuring\n);
+ return -ENOENT;
+ }
+
+ maddr = get_property(dn, mac-address, NULL);
+ if (maddr == NULL) {
+ dev_warn(pdev-dev,
+no mac address in device tree, not configuring\n);
+ return -ENOENT;
+ }
+
+ if (sscanf(maddr, %hhx:%hhx:%hhx:%hhx:%hhx:%hhx, addr[0],
+ addr[1], addr[2], addr[3], addr[4], addr[5]) != 6) {
+ dev_warn(pdev-dev,
+can't parse mac address, not configuring\n);
+ return -EINVAL;
+ }
+
+ memcpy(mac-mac_addr, addr, sizeof(addr));
+ return 0;
+}
+
+static int pasemi_mac_setup_rx_resources(struct net_device *dev)
+{
+ struct pasemi_mac_rxring *ring;
+ struct pasemi_mac *mac = netdev_priv(dev);
+ int chan_id = mac-dma_rxch;
+
+ ring = kzalloc(sizeof(*ring), GFP_KERNEL);
+
+ if (!ring)
+ goto out_ring;
+
+ ring-count = INITIAL_RX_RING_SIZE;
+
+ ring-desc_info = kzalloc(sizeof(struct pasemi_mac_buffer)*ring-count,
+ GFP_KERNEL);
+
+ if (!ring-desc_info)
+ goto out_desc_info;
+
+ /* Allocate descriptors */
+ ring-desc = (void *)__get_free_pages(GFP_KERNEL,
+ get_order(ring-count *
+ sizeof(struct
Re: [PATCH] PA Semi PWRficient Ethernet driver
Olof Johansson wrote:
On Mon, Jan 29, 2007 at 10:22:33AM -0800, Stephen Hemminger wrote:
Basic initalization, setup comments.
Thanks, fixes have been incorporated and will be reposted. Most of them
was obviously just my lack of diligence. See however the two below.
+static irqreturn_t pasemi_mac_tx_intr(int irq, void *data)
+{
+ struct net_device *dev = data;
+ struct pasemi_mac *mac = netdev_priv(dev);
+ unsigned int reg;
+
+ pasemi_mac_clean_tx(mac);
+
+ reg = PAS_IOB_DMA_TXCH_RESET_PINTC | PAS_IOB_DMA_TXCH_RESET_SINTC;
+ if (*mac-tx_status PAS_STATUS_TIMER)
+ reg |= PAS_IOB_DMA_TXCH_RESET_TINTC;
+
+ pci_write_config_dword(mac-iob_pdev,
PAS_IOB_DMA_TXCH_RESET(mac-dma_txch),
+ reg);
+
+ return IRQ_HANDLED;
+}
To do shared IRQ's properly you need to check to see if
this is your device IRQ or not. Maybe reading config value?
Right now it's guaranteed that the interrupts will not be shared. They're
fixed for the on-chip devices, and no other driver should be binding to
the same channels (and thus irqs).
If it changes in the future, the driver would need other rework as well.
Nonetheless, it is far more sane to check for work, and return if no
work. Who knows if the hardware will signal an interrupt early or late.
+static struct pci_driver pasemi_mac_driver = {
+ .name = pasemi_mac,
+ .id_table = pasemi_mac_pci_tbl,
+ .probe = pasemi_mac_probe,
Don't you need a remove routine?
No hotplug support at this time, so I didn't see any use in providing one.
module remove.
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: Hidden SSID's
On Sun, 2007-01-28 at 22:28 +0100, Johannes Berg wrote: On Sat, 2007-01-27 at 07:08 -0500, Dan Williams wrote: I really, really don't know why ieee80211 uses hidden, but it's a pain in the ass and should NOT be done for d80211. I don't know if we can ever remove it from ieee80211 though for backwards compat reasons. Ugh. /me makes a note for the cfg80211/we compat layer. This is a mess :( Well, there's no way a userspace program could depend on all hidden SSID APs having the hidden tag, since if you stick in another, non-ieee80211-stack card it won't be like that. So I don't think we should care about hidden in d80211, but I don't think we can remove it from ieee80211 either. The only case where we'll care about it is if we move to common scan-result processing code, and there we may have to put a compat flag in that the driver can set or something. But we should definitely _not_ use hidden in d80211 or cfg80211, because any program depending on hidden just won't work with anything other than an ipw card. Dan - 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.20-rc6 1/2] ehea: Fixed wrong jumbo frames status query
This patch fixes the wrong query and logging of the per interface jumbo frames
enabled/disabled status.
Signed-off-by: Thomas Klein [EMAIL PROTECTED]
---
drivers/net/ehea/ehea.h |2 +-
drivers/net/ehea/ehea_main.c | 30 +++---
2 files changed, 24 insertions(+), 8 deletions(-)
diff -Nurp -X dontdiff linux-2.6.20-rc6/drivers/net/ehea/ehea.h
patched_kernel/drivers/net/ehea/ehea.h
--- linux-2.6.20-rc6/drivers/net/ehea/ehea.h2007-01-25 03:19:28.0
+0100
+++ patched_kernel/drivers/net/ehea/ehea.h 2007-01-29 18:32:02.0
+0100
@@ -39,7 +39,7 @@
#include asm/io.h
#define DRV_NAME ehea
-#define DRV_VERSIONEHEA_0044
+#define DRV_VERSIONEHEA_0045
#define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
| NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
diff -Nurp -X dontdiff linux-2.6.20-rc6/drivers/net/ehea/ehea_main.c
patched_kernel/drivers/net/ehea/ehea_main.c
--- linux-2.6.20-rc6/drivers/net/ehea/ehea_main.c 2007-01-25
03:19:28.0 +0100
+++ patched_kernel/drivers/net/ehea/ehea_main.c 2007-01-29 18:32:02.0
+0100
@@ -2316,6 +2316,7 @@ static int ehea_setup_single_port(struct
struct ehea_adapter *adapter = port-adapter;
struct hcp_ehea_port_cb4 *cb4;
u32 *dn_log_port_id;
+ int jumbo = 0;
sema_init(port-port_lock, 1);
port-state = EHEA_PORT_DOWN;
@@ -2357,13 +2358,25 @@ static int ehea_setup_single_port(struct
if (!cb4) {
ehea_error(no mem for cb4);
} else {
- cb4-jumbo_frame = 1;
- hret = ehea_h_modify_ehea_port(adapter-handle,
- port-logical_port_id,
- H_PORT_CB4, H_PORT_CB4_JUMBO,
- cb4);
- if (hret != H_SUCCESS) {
- ehea_info(Jumbo frames not activated);
+ hret = ehea_h_query_ehea_port(adapter-handle,
+ port-logical_port_id,
+ H_PORT_CB4,
+ H_PORT_CB4_JUMBO, cb4);
+
+ if (hret == H_SUCCESS) {
+ if (cb4-jumbo_frame)
+ jumbo = 1;
+ else {
+ cb4-jumbo_frame = 1;
+ hret = ehea_h_modify_ehea_port(adapter-handle,
+ port-
+ logical_port_id,
+ H_PORT_CB4,
+ H_PORT_CB4_JUMBO,
+ cb4);
+ if (hret == H_SUCCESS)
+ jumbo = 1;
+ }
}
kfree(cb4);
}
@@ -2402,6 +2415,9 @@ static int ehea_setup_single_port(struct
goto out_free;
}
+ ehea_info(%s: Jumbo frames are %sabled, dev-name,
+ jumbo == 1 ? en : dis);
+
port-netdev = dev;
ret = 0;
goto out;
-
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.20-rc6 2/2] ehea: Fixed missing tasklet_kill() call
NEQ-Tasklet wasn't killed when module is removed. Signed-off-by: Thomas Klein [EMAIL PROTECTED] --- drivers/net/ehea/ehea_main.c |1 + 1 files changed, 1 insertion(+) diff -Nurp -X dontdiff linux-2.6.20-rc6/drivers/net/ehea/ehea_main.c patched_kernel/drivers/net/ehea/ehea_main.c --- linux-2.6.20-rc6/drivers/net/ehea/ehea_main.c 2007-01-29 15:53:00.0 +0100 +++ patched_kernel/drivers/net/ehea/ehea_main.c 2007-01-29 15:53:34.0 +0100 @@ -2598,6 +2598,7 @@ static int __devexit ehea_remove(struct destroy_workqueue(adapter-ehea_wq); ibmebus_free_irq(NULL, adapter-neq-attr.ist1, adapter); + tasklet_kill(adapter-neq_tasklet); ehea_destroy_eq(adapter-neq); - 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] rename members in dummy _xt_align struct
i'd like to rename the members in the _xt_align struct in
netfilter/x_tables.h ... by not using 'u8', 'u16', etc..., it's possible to
filter headers meant for userspace through the preprocessor and pull out
people who accidentally utilize these internal types ... however, by using
struct members who have the same name as 'u8', 'u16', etc..., this throws up
a false positive
of all the exported headers, this is the only one to do this sort of thing, so
i hope you guys wont mind making the change :)
-mike
pgpt2pRdwcKRD.pgp
Description: PGP signature
Use diff variable names than the standard type so we can run automated script
checks on the code to easily pull out export violations.
Signed-off-by: Mike Frysinger [EMAIL PROTECTED]
--- a/include/linux/netfilter/x_tables.h
+++ b/include/linux/netfilter/x_tables.h
@@ -82,10 +84,10 @@ struct xt_get_revision
*/
struct _xt_align
{
- u_int8_t u8;
- u_int16_t u16;
- u_int32_t u32;
- u_int64_t u64;
+ u_int8_t align_u8;
+ u_int16_t align_u16;
+ u_int32_t align_u32;
+ u_int64_t align_u64;
};
#define XT_ALIGN(s) (((s) + (__alignof__(struct _xt_align)-1)) \
[PATCH] block MSI on Sony
The Sony VAIO BIOS resets to INTx on resume. This happens
after device resume, so device irq's get misrouted.
This hack turns off MSI on this laptop, until power management
initialization order is fixed.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
drivers/pci/quirks.c | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index ef882a8..9a64179 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -21,6 +21,7 @@ #include linux/pci.h
#include linux/init.h
#include linux/delay.h
#include linux/acpi.h
+#include linux/dmi.h
#include pci.h
/* The Mellanox Tavor device gives false positive parity errors
@@ -1779,6 +1780,37 @@ static void __devinit quirk_nvidia_ck804
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_CK804_PCIE,
quirk_nvidia_ck804_msi_ht_cap);
+
+/* On Sony VAIO laptop, BIOS resets MSI during resume. */
+static __initdata struct dmi_system_id sony_dmi_table[] = {
+ {
+ .ident = Sony Vaio,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Sony Corporation),
+ DMI_MATCH(DMI_PRODUCT_NAME, PCG-),
+ },
+ },
+ {
+ .ident = Sony Vaio,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Sony Corporation),
+ DMI_MATCH(DMI_PRODUCT_NAME, VGN-),
+ },
+ },
+ { }
+};
+
+static void __init quirk_sony_msi(struct pci_dev *dev)
+{
+ if (!dmi_check_system(sony_dmi_table))
+ return;
+
+ pci_msi_quirk = 1;
+ printk(KERN_WARNING PCI: MSI sony quirk detected. pci_msi_quirk
set.\n);
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801BA_6,
+ quirk_sony_msi);
+
#endif /* CONFIG_PCI_MSI */
EXPORT_SYMBOL(pcie_mch_quirk);
--
1.4.1
-
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] block MSI on Sony
On Mon, 2007-01-29 at 15:50 -0800, Stephen Hemminger wrote: The Sony VAIO BIOS resets to INTx on resume. This happens after device resume, so device irq's get misrouted. Err? My Sony VAIO does _NOT_ do that. It works fine without that. It's just the sky2 hackery which fucked up things. tglx - 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] block MSI on Sony
On Tue, 30 Jan 2007 01:22:54 +0100 Thomas Gleixner [EMAIL PROTECTED] wrote: On Mon, 2007-01-29 at 15:50 -0800, Stephen Hemminger wrote: The Sony VAIO BIOS resets to INTx on resume. This happens after device resume, so device irq's get misrouted. Err? My Sony VAIO does _NOT_ do that. It works fine without that. It's just the sky2 hackery which fucked up things. What machine and BIOS version? -- 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: [PATCH] block MSI on Sony
On Tue, 2007-01-30 at 01:22 +0100, Thomas Gleixner wrote: On Mon, 2007-01-29 at 15:50 -0800, Stephen Hemminger wrote: The Sony VAIO BIOS resets to INTx on resume. This happens after device resume, so device irq's get misrouted. Err? My Sony VAIO does _NOT_ do that. It works fine without that. It's just the sky2 hackery which fucked up things. And how is this going to solve the breakage on Frederics box? I see the same symptoms on my Intel Mac Mini, and reverting the commit also allows the driver to seemingly resume correctly. Still it stands: Your sky2 patch #44ade178249fe53d055fd92113eaa271e06acddd is broken. Just get it. tglx - 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] block MSI on Sony
On Mon, 2007-01-29 at 16:21 -0800, Stephen Hemminger wrote: The Sony VAIO BIOS resets to INTx on resume. This happens after device resume, so device irq's get misrouted. Err? My Sony VAIO does _NOT_ do that. It works fine without that. It's just the sky2 hackery which fucked up things. What machine and BIOS version? VGN-SZ2XP_C BIOS: R0081N0 tglx - 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] block MSI on Sony
On Tue, 30 Jan 2007 01:31:33 +0100 Thomas Gleixner [EMAIL PROTECTED] wrote: On Mon, 2007-01-29 at 16:21 -0800, Stephen Hemminger wrote: The Sony VAIO BIOS resets to INTx on resume. This happens after device resume, so device irq's get misrouted. Err? My Sony VAIO does _NOT_ do that. It works fine without that. It's just the sky2 hackery which fucked up things. What machine and BIOS version? VGN-SZ2XP_C BIOS: R0081N0 Mine is: VGN-N170G BIOS: R0020J4 It might be BIOS bug that has been fixed, but updating the BIOS requires Windows. It checks for some ID so even Wine won't work. -- 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: Hidden SSID's
On Mon, 2007-01-29 at 19:09 -0800, Jouni Malinen wrote: On Mon, Jan 29, 2007 at 08:00:11AM -0500, Dan Williams wrote: Well, there's no way a userspace program could depend on all hidden SSID APs having the hidden tag, since if you stick in another, non-ieee80211-stack card it won't be like that. So I don't think we should care about hidden in d80211, but I don't think we can remove it from ieee80211 either. Use of 'hidden' is just not acceptable. IMHO, it should be removed from everywhere, including net/ieee80211. The sooner this is done, the better. You're probably right. Lets just pull it out of ieee80211 and be done. dan - 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: Hidden SSID's
On Mon, Jan 29, 2007 at 08:00:11AM -0500, Dan Williams wrote: Well, there's no way a userspace program could depend on all hidden SSID APs having the hidden tag, since if you stick in another, non-ieee80211-stack card it won't be like that. So I don't think we should care about hidden in d80211, but I don't think we can remove it from ieee80211 either. Use of 'hidden' is just not acceptable. IMHO, it should be removed from everywhere, including net/ieee80211. The sooner this is done, the better. -- 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: Hidden SSID's
Dan Williams wrote:
On Mon, 2007-01-29 at 19:09 -0800, Jouni Malinen wrote:
On Mon, Jan 29, 2007 at 08:00:11AM -0500, Dan Williams wrote:
Well, there's no way a userspace program could depend on all hidden SSID
APs having the hidden tag, since if you stick in another,
non-ieee80211-stack card it won't be like that. So I don't think we
should care about hidden in d80211, but I don't think we can remove it
from ieee80211 either.
Use of 'hidden' is just not acceptable. IMHO, it should be removed
from everywhere, including net/ieee80211. The sooner this is done, the
better.
You're probably right. Lets just pull it out of ieee80211 and be done.
Before it gets pulled, please look at this patch.
Larry
===
When an AP has a hidden SSID, ieee80211 fails, at least with wpa_supplicant,
which searches through the scan data looking for a particular ssid. Because
ieee80211 has substituted a false ssid, namely hidden, wpa_supplicant
cannot authenticate. This behavior is fixed by adding a new argument to
ieee80211_translate_scan that contains the expected ssid. A new routine,
ieee80211_wx_get_scan_essid, has an additional argument that contains the essid
of the AP that wpa_supplicant is trying to find. The existing routine,
ieee80211_wx_get_scan, calls the new one with the false ssid. The code in
ieee80211softmac is also modified to use the new routine and has been tested
with bcm43xx.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
Index: linux-2.6/include/net/ieee80211.h
===
--- linux-2.6.orig/include/net/ieee80211.h
+++ linux-2.6/include/net/ieee80211.h
@@ -946,6 +946,11 @@ struct ieee80211_network {
struct list_head list;
};
+struct ieee80211_essid {
+ u8 len;
+ char data[IW_ESSID_MAX_SIZE];
+};
+
enum ieee80211_state {
IEEE80211_UNINITIALIZED = 0,
IEEE80211_INITIALIZED,
@@ -1296,6 +1301,10 @@ extern const struct ieee80211_channel *i
extern int ieee80211_wx_get_scan(struct ieee80211_device *ieee,
struct iw_request_info *info,
union iwreq_data *wrqu, char *key);
+extern int ieee80211_wx_get_scan_essid(struct ieee80211_device *ieee,
+struct iw_request_info *info,
+union iwreq_data *wrqu, char *key,
+struct ieee80211_essid *essid);
extern int ieee80211_wx_set_encode(struct ieee80211_device *ieee,
struct iw_request_info *info,
union iwreq_data *wrqu, char *key);
Index: linux-2.6/net/ieee80211/ieee80211_wx.c
===
--- linux-2.6.orig/net/ieee80211/ieee80211_wx.c
+++ linux-2.6/net/ieee80211/ieee80211_wx.c
@@ -44,7 +44,8 @@ static const char *ieee80211_modes[] = {
#define MAX_CUSTOM_LEN 64
static char *ieee80211_translate_scan(struct ieee80211_device *ieee,
char *start, char *stop,
- struct ieee80211_network *network)
+ struct ieee80211_network *network,
+ struct ieee80211_essid *essid)
{
char custom[MAX_CUSTOM_LEN];
char *p;
@@ -65,10 +66,10 @@ static char *ieee80211_translate_scan(st
iwe.cmd = SIOCGIWESSID;
iwe.u.data.flags = 1;
if (network-flags NETWORK_EMPTY_ESSID) {
- iwe.u.data.length = sizeof(hidden);
- start = iwe_stream_add_point(start, stop, iwe, hidden);
+ iwe.u.data.length = min(essid-len, (u8) IW_ESSID_MAX_SIZE);
+ start = iwe_stream_add_point(start, stop, iwe, essid-data);
} else {
- iwe.u.data.length = min(network-ssid_len, (u8) 32);
+ iwe.u.data.length = min(network-ssid_len, (u8)
IW_ESSID_MAX_SIZE);
start = iwe_stream_add_point(start, stop, iwe, network-ssid);
}
@@ -247,9 +248,15 @@ static char *ieee80211_translate_scan(st
#define SCAN_ITEM_SIZE 128
-int ieee80211_wx_get_scan(struct ieee80211_device *ieee,
+static struct ieee80211_essid hidden_essid = {
+ .len = sizeof (hidden),
+ .data = {hidden},
+};
+
+int ieee80211_wx_get_scan_essid(struct ieee80211_device *ieee,
struct iw_request_info *info,
- union iwreq_data *wrqu, char *extra)
+ union iwreq_data *wrqu, char *extra,
+ struct ieee80211_essid *essid)
{
struct ieee80211_network *network;
unsigned long flags;
@@ -272,7 +279,7 @@ int ieee80211_wx_get_scan(struct ieee802
if (ieee-scan_age == 0 ||
time_after(network-last_scanned + ieee-scan_age, jiffies))
- ev = ieee80211_translate_scan(ieee, ev,
Re: Hidden SSID's
On Mon, Jan 29, 2007 at 10:52:20PM -0600, Larry Finger wrote: When an AP has a hidden SSID, ieee80211 fails, at least with wpa_supplicant, which searches through the scan data looking for a particular ssid. Because ieee80211 has substituted a false ssid, namely hidden, wpa_supplicant cannot authenticate. This behavior is fixed by adding a new argument to ieee80211_translate_scan that contains the expected ssid. Would this be replacing the SSID of all BSSes in scan results with the SSID for which the latest per-SSID scan was issued? If yes, this does not sound any better than the current behavior. The driver/802.11 code should not replace the SSID value with anything else than the value received from the AP. In case of hidden SSIDs, the 802.11 implementation should maintain a list of BSSes found during the scan(s) and update the SSID (in most cases, by creating a new BSS entry) with the SSID from Probe Response frames. In other words, if the scan is done for a specific SSID (Probe Request includes that SSID), the AP that is using hidden SSIDs will likely include the SSID in Probe Response and data from that Probe Response can be used to fill in the missing pieces for the BSSID,SSID pair. Generating false scan results by locally guessing what the SSID could be is just plain wrong. The scan results need to be based on real frames from the APs. -- 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
[Patch][IPv6] Fix wrong routing mechanism for Link Local IPv6 packets
Hi, all When I tested linux-2.6.19.2, and found maybe there're some packet routing bugs in linux kernel. My test topology is shown as the following: eth0: fe80::20c:29ff:fe24:fa0a | eth1: fe80::20c:29ff:fe24:fa14 | | | | | | | LAN1 |LAN2 | | - ^ | Send Echo Request(src addr = fe80::200:ff:fe00:100) Now we send Echo Request to eth1(ipv6 src addr is fe80::200:ff:fe00:100, ipv6 dst addr is fe80::20c:29ff:fe24:fa14) on LAN1. Linux will send ICMPv6 Redirect Packet to us. And the TargetAddress = fe80::20c:29ff:fe24:fa14, DestinationAddress = fe80::20c:29ff:fe24:fa14. Obviously, Linux considers that fe80::200:ff:fe00:100 and fe80::20c:29ff:fe24:fa14 is on the SAME link(LAN0). In fact, kernel invoke function ip6_foward(). When Linux decides whether or not making use of a rt6_info entry, it will match the rt-rt6i_idev and rt-rt6_dev. This is done in function rt6_check_dev(). If nothing matched, rt6_check_dev() return 0. Then function rt6_score_route() will check whether the matched ipv6 addr (fe80::20c:29ff:fe24:fa14 in our example) is a link local ipv6 address. If it is a link local address, and rt-rt6i_idev rt-rt6_dev match failed -- rt6_check_dev() return 0. Function rt6_score_route() return -1 directly. I think here is a problem. When kernel match eth1 addr with rt6_info entries, it will lookup in local_table first. In rt6_check_dev() matching rt-rt6i_idev rt- rt6_dev will fail. The reason is oif = 2 , rt-rt6i_idev-dev-ifindex is 3 and rt-rt6i_dev-ifindex is 1. I think even this match failed, rt6_score_route() should not return -1, but return 0. And I think check for RT6_LOOKUP_F_IFACE flag isn't needed here. Checking for this flag is only needed in route cache when matching dst addr. Due to the reason mentioned above, all entries in local table matching dst addr fe80::20c:29ff:fe24:fa14 are failed. And then kernel matches main table. fe80::/64 entry in main table will match successfully. Later ip6_rt_copy() will copy the function pointer rt-u.dst.input. Obviously rt-u.dst.input in main table is ip6_forward(). The following is my patch. signed-off-by: Wei Dong [EMAIL PROTECTED] diff -ruN old/net/ipv6/route.c new/net/ipv6/route.c --- old/net/ipv6/route.c2007-01-10 14:10:37.0 -0500 +++ new/net/ipv6/route.c2007-01-17 18:24:51.336774016 -0500 @@ -343,7 +343,7 @@ int m, n; m = rt6_check_dev(rt, oif); - if (!m (strict RT6_LOOKUP_F_IFACE)) + if (!m (rt-rt6i_flags RTF_CACHE) (strict RT6_LOOKUP_F_IFACE)) return -1; #ifdef CONFIG_IPV6_ROUTER_PREF m |= IPV6_DECODE_PREF(IPV6_EXTRACT_PREF(rt-rt6i_flags)) 2; - 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][IPv6] Fix wrong routing mechanism for Link Local IPv6 packets
Hello. In article [EMAIL PROTECTED] (at Wed, 21 Feb 2007 02:24:26 -0500), weidong [EMAIL PROTECTED] says: eth0: fe80::20c:29ff:fe24:fa0a | eth1: fe80::20c:29ff:fe24:fa14 | | | | | | | LAN1 |LAN2 | | - ^ | Send Echo Request(src addr = fe80::200:ff:fe00:100) Sorry, I could not understand this figure Would you elaborate this? --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: RFC: Provide setting of Link Partner Autonegotiation
On Jan 20, 2007, at 4:49 PM, Kumar Gala wrote:
Here's the start of a patch to provide the state of the link
partner's autoneg. This is useful to know if the link partner is
trying to force a speed and we aren't matching.
I wasn't sure how to handle this for all the drivers that handle
phy's themselves. Is there some way to have this set to a 'not
supported value' in ethtool_get_settings and leave it to the driver
specific function to modify it?
I'll followup with an ethtool patch once we figure out the kernel
side.
- kumar
Jeff,
What are your thoughts on adding some defines like:
LPA_NOT_IMPLEMENTED /* device/driver has determined if it can
implement this feature */
LPA_NOT_SUPPORTED /* device/driver doesn't support this information */
By default we'd set the field to LPA_NOT_IMPLEMENTED and than let the
driver's get_settings callback modify it as appropriate?
- k
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index e175f39..77694d5 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -299,6 +299,7 @@ int phy_ethtool_gset(struct phy_device *phydev,
struct ethtool_cmd *cmd)
cmd-phy_address = phydev-addr;
cmd-transceiver = XCVR_EXTERNAL;
cmd-autoneg = phydev-autoneg;
+ cmd-lp_autoneg = phydev-link_partner_autoneg;
return 0;
}
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/
phy_device.c
index a4d7529..a7137c8 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -62,6 +62,7 @@ struct phy_device* phy_device_create(struct
mii_bus *bus, int addr, int phy_id)
dev-interface = PHY_INTERFACE_MODE_GMII;
dev-autoneg = AUTONEG_ENABLE;
+ dev-link_partner_autoneg = AUTONEG_ENABLE;
dev-addr = addr;
dev-phy_id = phy_id;
@@ -441,6 +442,16 @@ int genphy_update_link(struct phy_device *phydev)
else
phydev-link = 1;
+ /* Read Auto-Negotiation Expansion */
+ status = phy_read(phydev, MII_EXPANSION);
+ if (status 0)
+ return status;
+
+ if (status EXPANSION_NWAY)
+ phydev-link_partner_autoneg = AUTONEG_ENABLE;
+ else
+ phydev-link_partner_autoneg = AUTONEG_DISABLE;
+
return 0;
}
EXPORT_SYMBOL(genphy_update_link);
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index c6310ae..18b0b17 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -26,7 +26,8 @@ struct ethtool_cmd {
__u8autoneg;/* Enable or disable autonegotiation */
__u32 maxtxpkt; /* Tx pkts before generating tx int */
__u32 maxrxpkt; /* Rx pkts before generating rx int */
- __u32 reserved[4];
+ __u32 lp_autoneg; /* Link partner's ability for autonegotiation */
+ __u32 reserved[3];
};
#define ETHTOOL_BUSINFO_LEN32
diff --git a/include/linux/phy.h b/include/linux/phy.h
index edd4c88..f91a9c0 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -269,6 +269,8 @@ struct phy_device {
int link_timeout;
+ int link_partner_autoneg;
+
/* Interrupt number for this PHY
* -1 means no interrupt */
int irq;
-
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][IPv6] Fix wrong routing mechanism for Link Local IPv6 packets
Hello, Mr yoshfuji Take ping6 for example. Asumming there is a router which has 2 NICs. eth0 on router has ipv6 addr fe80::20c:29ff:fe24:fa0a, eth1 on router has ipv6 addr fe80::20c:29ff:fe24:fa14. Also there is a host connected to router's eth0, and the host's ipv6 addr is fe80::200:ff:fe00:100. We ping6 to router's eth1(ipv6 addr fe80::20c:29ff:fe24:fa14). But now Linux kernel deals with this kind of packet incorrectly. Router forward the Echo request to eth0. And send ICMP redirect packet to the host. In ICMP redirect packt TargetAddress =fe80::20c:29ff:fe24:fa14, DestinationAddress = fe80::20c:29ff:fe24:fa14. So I think Linux kernel considers that fe80::200:ff:fe00:100 and fe80::20c:29ff:fe24:fa14 are neighbors. I dived into the kernel, and found that maybe function rt6_score_route() has problems. In rt6_score_route(), if rt6_check_dev() return 0, and the dst ipv6 addr is link local addr, rt6_socre_route() return -1 directly. I think this is not correct, we should return -1 only if the entry is in the route cache, and the dst addr is link local addr. Only entries in cache will select wrong IPv6 Link Local NIC for a link local addr, because they are copied from static IPv6 fib tables. - Original Message - Hello. In article [EMAIL PROTECTED] (at Wed, 21 Feb 2007 02:24:26 -0500), weidong [EMAIL PROTECTED] says: eth0: fe80::20c:29ff:fe24:fa0a | eth1: fe80::20c:29ff:fe24:fa14 | | | | | | | LAN1 |LAN2 | | - ^ | Send Echo Request(src addr = fe80::200:ff:fe00:100) Sorry, I could not understand this figure Would you elaborate this? --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: Hidden SSID's
Jouni Malinen wrote: On Mon, Jan 29, 2007 at 10:52:20PM -0600, Larry Finger wrote: When an AP has a hidden SSID, ieee80211 fails, at least with wpa_supplicant, which searches through the scan data looking for a particular ssid. Because ieee80211 has substituted a false ssid, namely hidden, wpa_supplicant cannot authenticate. This behavior is fixed by adding a new argument to ieee80211_translate_scan that contains the expected ssid. Would this be replacing the SSID of all BSSes in scan results with the SSID for which the latest per-SSID scan was issued? If yes, this does not sound any better than the current behavior. The driver/802.11 code should not replace the SSID value with anything else than the value received from the AP. Any AP with a hidden SSID will only respond to probe requests that specify its SSID, and will ignore any other probes. In addition, the response will have an empty SSID field. These responses are the only ones in which a substitution would occur. These are the same responses where the current code sends back the hidden pseudo-SSID. My change would put the correct one there. In case of hidden SSIDs, the 802.11 implementation should maintain a list of BSSes found during the scan(s) and update the SSID (in most cases, by creating a new BSS entry) with the SSID from Probe Response frames. In other words, if the scan is done for a specific SSID (Probe Request includes that SSID), the AP that is using hidden SSIDs will likely include the SSID in Probe Response and data from that Probe Response can be used to fill in the missing pieces for the BSSID,SSID pair. Generating false scan results by locally guessing what the SSID could be is just plain wrong. The scan results need to be based on real frames from the APs. We aren't guessing. The response frame with the empty SSID field must have come from the AP with the SSID we want. Filling in the expected value is just making it easier for the user-space tools. 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
