* Re: [RFC IPROUTE 00/05]: Time cleanups
From: Patrick McHardy @ 2006-06-23 18:09 UTC (permalink / raw)
To: shemminger; +Cc: netdev, hadi
In-Reply-To: <20060623180642.13183.74864.sendpatchset@localhost.localdomain>
D'oh, got Stephen's address wrong. Please fix it (add 's' in front) in
replies to this thread.
Patrick McHardy wrote:
> I'm currently adding support for ktime as clocksource to the qdisc layer and
> in the course of doing that cleaned up the iproute time handling a bit to
> make it easier to use a different internal clock resultion and audit for
> integer overflows.
>
> Increasing iproutes internal clock resolution is necessary for all token bucket
> based schedulers to take advantage of a higher kernel clock resolution because
> the kernel only does lookups and additions/subtractions, which can never result
> in values that have a higher precision that those passed from userspace.
>
> The way I imagine it we have to keep the old clock sources around for userspace
> compatibility since they can't deal with the higher precision values. iproute is
> changed to use nsec internally and reads the kernel clock resulution from
> /proc/net/psched (third value, currently assumed to always be 10^6) to convert
> it's internal resolution to that of the kernel. With ktime as clocksource the
> kernel will report a resulution of 10^9. The downside is that distributors can't
> enable ktime unless they want to break compatibility with old iproute versions.
> Any better suggestions are welcome of course.
>
>
> tc/m_estimator.c | 4 ++--
> tc/m_police.c | 2 +-
> tc/q_cbq.c | 15 ++++++++-------
> tc/q_hfsc.c | 18 +++++++++---------
> tc/q_htb.c | 4 ++--
> tc/q_netem.c | 12 +++---------
> tc/q_tbf.c | 20 ++++++++++----------
> tc/tc_cbq.c | 8 ++++----
> tc/tc_core.c | 31 +++++++++++++++++++++++--------
> tc/tc_core.h | 9 +++++++--
> tc/tc_estimator.c | 2 +-
> tc/tc_red.c | 2 +-
> tc/tc_util.c | 33 +++++++++++++++++++--------------
> tc/tc_util.h | 7 ++++---
> 14 files changed, 94 insertions(+), 73 deletions(-)
>
> Patrick McHardy:
> [IPROUTE]: Use tc_calc_xmittime where appropriate
> [IPROUTE]: Introduce tc_calc_xmitsize and use where appropriate
> [IPROUTE]: Introduce TIME_UNITS_PER_SEC to represent internal clock resulution
> [IPROUTE]: Replace "usec" by "time" in function names
> [IPROUTE]: Add sprint_ticks() function and use in CBQ
^ permalink raw reply
* [PATCH 0/3] d80211: AP mode fixes
From: Jiri Benc @ 2006-06-23 18:16 UTC (permalink / raw)
To: netdev; +Cc: John W. Linville, Michael Buesch, Alexander Tsvyashchenko
This a series of experimental AP mode fixes.
It is also available (together with patches for bcm43xx AP mode support) in
a 'devel' branch of my dscape tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/jbenc/dscape.git devel
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* [PATCH 1/3] d80211: do not receive through master interface
From: Jiri Benc @ 2006-06-23 18:16 UTC (permalink / raw)
To: netdev; +Cc: John W. Linville, Michael Buesch, Alexander Tsvyashchenko
In-Reply-To: <20060623201604.835047000.midnight@suse.cz>
Arrived packets should not go into master interface - it leads to duplicate
packets reception.
Signed-off-by: Jiri Benc <jbenc@suse.cz>
---
net/d80211/ieee80211.c | 4 ++++
1 files changed, 4 insertions(+)
--- dscape.orig/net/d80211/ieee80211.c
+++ dscape/net/d80211/ieee80211.c
@@ -3586,6 +3586,10 @@ void __ieee80211_rx(struct net_device *d
!ieee80211_bssid_match(bssid,
sdata->dev->dev_addr))
continue;
+ if (sdata->dev == sdata->master)
+ /* do not receive anything via
+ * master device */
+ continue;
break;
case IEEE80211_IF_TYPE_WDS:
if (bssid ||
^ permalink raw reply
* [PATCH 2/3] d80211: host_gen_beacon_template flag
From: Jiri Benc @ 2006-06-23 18:16 UTC (permalink / raw)
To: netdev; +Cc: John W. Linville, Michael Buesch, Alexander Tsvyashchenko
In-Reply-To: <20060623201604.835047000.midnight@suse.cz>
This is a partial support for devices requiring beacon template. Please note
that there is no support for PS mode for such cards yet.
Signed-off-by: Jiri Benc <jbenc@suse.cz>
---
include/net/d80211.h | 6 ++++++
net/d80211/ieee80211.c | 22 +++++++++++++++++++++-
net/d80211/ieee80211_i.h | 1 +
net/d80211/ieee80211_ioctl.c | 2 +-
4 files changed, 29 insertions(+), 2 deletions(-)
--- dscape.orig/include/net/d80211.h
+++ dscape/include/net/d80211.h
@@ -349,6 +349,9 @@ struct ieee80211_if_init_conf {
* only during config_interface() callback (so copy the value somewhere
* if you need it).
* @generic_elem_len: length of the generic element.
+ * @beacon: beacon template. Valid only if @host_gen_beacon_template in
+ * &struct ieee80211_hw is set. The driver is responsible of freeing
+ * the sk_buff.
*
* This structure is passed to config_interface() callback of
* &struct ieee80211_hw.
@@ -360,6 +363,7 @@ struct ieee80211_if_conf {
size_t ssid_len;
u8 *generic_elem;
size_t generic_elem_len;
+ struct sk_buff *beacon;
};
typedef enum { ALG_NONE, ALG_WEP, ALG_TKIP, ALG_CCMP, ALG_NULL }
@@ -439,6 +443,8 @@ struct ieee80211_hw {
* beacon frame. */
int host_gen_beacon:1;
+ /* The device needs to be supplied with a beacon template only. */
+ int host_gen_beacon_template:1;
/* Some devices handle decryption internally and do not
* indicate whether the frame was encrypted (unencrypted frames
--- dscape.orig/net/d80211/ieee80211.c
+++ dscape/net/d80211/ieee80211.c
@@ -1902,7 +1902,8 @@ ieee80211_get_buffered_bc(struct net_dev
return skb;
}
-int ieee80211_if_config(struct net_device *dev)
+static int __ieee80211_if_config(struct net_device *dev,
+ struct sk_buff *beacon)
{
struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
struct ieee80211_local *local = dev->ieee80211_ptr;
@@ -1925,10 +1926,29 @@ int ieee80211_if_config(struct net_devic
conf.ssid_len = sdata->u.ap.ssid_len;
conf.generic_elem = sdata->u.ap.generic_elem;
conf.generic_elem_len = sdata->u.ap.generic_elem_len;
+ conf.beacon = beacon;
}
return local->hw->config_interface(local->mdev, dev->ifindex, &conf);
}
+int ieee80211_if_config(struct net_device *dev)
+{
+ return __ieee80211_if_config(dev, NULL);
+}
+
+int ieee80211_if_config_beacon(struct net_device *dev)
+{
+ struct ieee80211_local *local = dev->ieee80211_ptr;
+ struct sk_buff *skb;
+
+ if (!local->hw->host_gen_beacon_template)
+ return 0;
+ skb = ieee80211_beacon_get(local->mdev, dev->ifindex, NULL);
+ if (!skb)
+ return -ENOMEM;
+ return __ieee80211_if_config(dev, skb);
+}
+
int ieee80211_hw_config(struct net_device *dev)
{
struct ieee80211_local *local = dev->ieee80211_ptr;
--- dscape.orig/net/d80211/ieee80211_i.h
+++ dscape/net/d80211/ieee80211_i.h
@@ -545,6 +545,7 @@ struct sta_attribute {
void ieee80211_release_hw(struct ieee80211_local *local);
int ieee80211_hw_config(struct net_device *dev);
int ieee80211_if_config(struct net_device *dev);
+int ieee80211_if_config_beacon(struct net_device *dev);
struct ieee80211_key_conf *
ieee80211_key_data2conf(struct ieee80211_local *local,
struct ieee80211_key *data);
--- dscape.orig/net/d80211/ieee80211_ioctl.c
+++ dscape/net/d80211/ieee80211_ioctl.c
@@ -110,7 +110,7 @@ static int ieee80211_ioctl_set_beacon(st
}
}
- return 0;
+ return ieee80211_if_config_beacon(dev);
}
^ permalink raw reply
* [PATCH 3/3] bcm43xx-d80211: use host_gen_beacon_template
From: Jiri Benc @ 2006-06-23 18:16 UTC (permalink / raw)
To: netdev; +Cc: John W. Linville, Michael Buesch, Alexander Tsvyashchenko
In-Reply-To: <20060623201604.835047000.midnight@suse.cz>
Use new host_gen_beacon_template flag. This also means workaround with
"iwconfig essid" after hostapd is run is not necessary anymore.
Signed-off-by: Jiri Benc <jbenc@suse.cz>
---
drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c | 36 ++++++---------------
1 files changed, 11 insertions(+), 25 deletions(-)
--- dscape.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
+++ dscape/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
@@ -1710,17 +1710,12 @@ static void bcm43xx_write_probe_resp_tem
kfree(probe_resp_data);
}
-static int bcm43xx_refresh_cached_beacon(struct bcm43xx_private *bcm)
+static int bcm43xx_refresh_cached_beacon(struct bcm43xx_private *bcm,
+ struct sk_buff *beacon)
{
- struct ieee80211_tx_control control;
-
if (bcm->cached_beacon)
kfree_skb(bcm->cached_beacon);
- bcm->cached_beacon = ieee80211_beacon_get(bcm->net_dev,
- bcm->interface.if_id,
- &control);
- if (unlikely(!bcm->cached_beacon))
- return -ENOMEM;
+ bcm->cached_beacon = beacon;
return 0;
}
@@ -1743,16 +1738,15 @@ static void bcm43xx_update_templates(str
bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS2_BITFIELD, status);
}
-static void bcm43xx_refresh_templates(struct bcm43xx_private *bcm)
+static void bcm43xx_refresh_templates(struct bcm43xx_private *bcm,
+ struct sk_buff *beacon)
{
int err;
- err = bcm43xx_refresh_cached_beacon(bcm);
+ err = bcm43xx_refresh_cached_beacon(bcm, beacon);
if (unlikely(err))
return;
bcm43xx_update_templates(bcm);
- kfree_skb(bcm->cached_beacon);
- bcm->cached_beacon = NULL;
}
static void bcm43xx_set_ssid(struct bcm43xx_private *bcm,
@@ -1792,19 +1786,11 @@ static void bcm43xx_set_beacon_int(struc
static void handle_irq_beacon(struct bcm43xx_private *bcm)
{
u32 status;
- int err;
bcm->irq_savedstate &= ~BCM43xx_IRQ_BEACON;
status = bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS2_BITFIELD);
- if (!bcm->cached_beacon) {
- err = bcm43xx_refresh_cached_beacon(bcm);
- if (unlikely(err))
- goto ack;
- }
-
- if ((status & 0x1) && (status & 0x2)) {
-ack:
+ if (!bcm->cached_beacon || ((status & 0x1) && (status & 0x2))) {
/* ACK beacon IRQ. */
bcm43xx_write32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON,
BCM43xx_IRQ_BEACON);
@@ -4382,7 +4368,6 @@ static int bcm43xx_net_config(struct net
if (bcm43xx_is_mode(bcm, IEEE80211_IF_TYPE_AP)) {
bcm43xx_set_beacon_int(bcm, conf->beacon_int);
- bcm43xx_refresh_templates(bcm);
}
bcm43xx_unlock_irqonly(bcm, flags);
@@ -4553,7 +4538,7 @@ static int bcm43xx_add_interface(struct
if (bcm43xx_status(bcm) == BCM43xx_STAT_INITIALIZED) {
bcm43xx_select_opmode(bcm);
if (bcm43xx_is_mode(bcm, IEEE80211_IF_TYPE_AP))
- bcm43xx_refresh_templates(bcm);
+ bcm43xx_refresh_templates(bcm, NULL);
}
err = 0;
@@ -4606,7 +4591,8 @@ static int bcm43xx_config_interface(stru
if (bcm43xx_is_mode(bcm, IEEE80211_IF_TYPE_AP)) {
assert(conf->type == IEEE80211_IF_TYPE_AP);
bcm43xx_set_ssid(bcm, conf->ssid, conf->ssid_len);
- bcm43xx_refresh_templates(bcm);
+ if (conf->beacon)
+ bcm43xx_refresh_templates(bcm, conf->beacon);
}
}
bcm43xx_unlock_irqsafe(bcm, flags);
@@ -4701,7 +4687,7 @@ static int __devinit bcm43xx_init_one(st
goto out;
ieee->version = IEEE80211_VERSION;
ieee->name = KBUILD_MODNAME;
- ieee->host_gen_beacon = 1;
+ ieee->host_gen_beacon_template = 1;
ieee->rx_includes_fcs = 1;
ieee->monitor_during_oper = 1;
ieee->tx = bcm43xx_net_hard_start_xmit;
^ permalink raw reply
* hostapd patch for d80211
From: Jiri Benc @ 2006-06-23 18:19 UTC (permalink / raw)
To: Michael Buesch
Cc: bcm43xx-dev, netdev, Alexander Tsvyashchenko, Francois Barre,
Jouni Malinen
In-Reply-To: <200606191107.34602.mb@bu3sch.de>
On Mon, 19 Jun 2006 11:07:34 +0200, Michael Buesch wrote:
> Important notes from Alexander Tsvyashchenko's initial mail follow:
> [...]
> Although my previous patch to hostapd to make it interoperable with
> bcm43xx & dscape has been merged already in their CVS version, due to
> the subsequent changes in dscape stack current hostapd is again
> incompartible :-(
This patch allows devicescape driver in hostapd to work with recent d80211.
No manipulation with network interfaces is needed anymore - hostapd even
switches the interface to AP mode automatically now. Just modprobe
bcm43xx-d80211, run hostapd and enjoy :-)
Signed-off-by: Jiri Benc <jbenc@suse.cz>
---
driver_devicescape.c | 77 ++++++++++++++++++++++++++++++++++++++++++---------
1 files changed, 64 insertions(+), 13 deletions(-)
--- hostapd-0.5-2006-06-19.orig/driver_devicescape.c
+++ hostapd-0.5-2006-06-19/driver_devicescape.c
@@ -73,6 +73,7 @@ struct i802_driver_data {
char iface[IFNAMSIZ + 1];
char mgmt_iface[IFNAMSIZ + 1];
+ int mgmt_ifindex;
int sock; /* raw packet socket for driver access */
int ioctl_sock; /* socket for ioctl() use */
int wext_sock; /* socket for wireless events */
@@ -88,6 +89,21 @@ static const struct driver_ops devicesca
static int i802_sta_set_flags(void *priv, const u8 *addr,
int flags_or, int flags_and);
+static int i802_set_ap_mode(struct i802_driver_data *drv)
+{
+ struct iwreq iwr;
+
+ memset(&iwr, 0, sizeof(iwr));
+ strncpy(iwr.ifr_name, drv->iface, IFNAMSIZ);
+ iwr.u.mode = IW_MODE_MASTER;
+
+ if (ioctl(drv->ioctl_sock, SIOCSIWMODE, &iwr) < 0) {
+ perror("ioctl[SIOCSIWMODE]");
+ return -1;
+ }
+
+ return 0;
+}
static int hostapd_set_iface_flags(struct i802_driver_data *drv, int dev_up)
{
@@ -96,13 +112,16 @@ static int hostapd_set_iface_flags(struc
if (drv->ioctl_sock < 0)
return -1;
+ if (dev_up)
+ i802_set_ap_mode(drv);
+
memset(&ifr, 0, sizeof(ifr));
- snprintf(ifr.ifr_name, IFNAMSIZ, "%s", drv->mgmt_iface);
+ snprintf(ifr.ifr_name, IFNAMSIZ, "%s", drv->iface);
if (ioctl(drv->ioctl_sock, SIOCGIFFLAGS, &ifr) != 0) {
perror("ioctl[SIOCGIFFLAGS]");
wpa_printf(MSG_DEBUG, "Could not read interface flags (%s)",
- drv->mgmt_iface);
+ drv->iface);
return -1;
}
@@ -303,7 +322,35 @@ static int hostap_ioctl_prism2param(stru
return hostap_ioctl_prism2param_iface(drv->iface, drv, param, value);
}
-
+static int hostap_ioctl_get_prism2param_iface(const char *iface,
+ struct i802_driver_data *drv,
+ int param)
+{
+ struct iwreq iwr;
+ int *i;
+
+ memset(&iwr, 0, sizeof(iwr));
+ strncpy(iwr.ifr_name, iface, IFNAMSIZ);
+ i = (int *) iwr.u.name;
+ *i = param;
+
+ if (ioctl(drv->ioctl_sock, PRISM2_IOCTL_GET_PRISM2_PARAM, &iwr) < 0) {
+ char buf[128];
+ snprintf(buf, sizeof(buf),
+ "%s: ioctl[PRISM2_IOCTL_GET_PRISM2_PARAM]", iface);
+ perror(buf);
+ return -1;
+ }
+
+ return *i;
+}
+
+static int hostap_ioctl_get_prism2param(struct i802_driver_data *drv,
+ int param)
+{
+ return hostap_ioctl_get_prism2param_iface(drv->iface, drv, param);
+}
+
static int i802_set_ssid(void *priv, const u8 *buf, int len)
{
struct i802_driver_data *drv = priv;
@@ -1338,12 +1385,20 @@ static int i802_init_sockets(struct i802
return -1;
}
+ /* Enable management interface */
+ if (hostap_ioctl_prism2param(drv, PRISM2_PARAM_MGMT_IF, 1) < 0)
+ return -1;
+ drv->mgmt_ifindex =
+ hostap_ioctl_get_prism2param(drv, PRISM2_PARAM_MGMT_IF);
+ if (drv->mgmt_ifindex < 0)
+ return -1;
memset(&ifr, 0, sizeof(ifr));
- snprintf(ifr.ifr_name, sizeof(ifr.ifr_name), "%s", drv->mgmt_iface);
- if (ioctl(drv->ioctl_sock, SIOCGIFINDEX, &ifr) != 0) {
- perror("ioctl(SIOCGIFINDEX)");
+ ifr.ifr_ifindex = drv->mgmt_ifindex;
+ if (ioctl(drv->ioctl_sock, SIOCGIFNAME, &ifr) != 0) {
+ perror("ioctl(SIOCGIFNAME)");
return -1;
}
+ snprintf(drv->mgmt_iface, sizeof(drv->mgmt_iface), "%s", ifr.ifr_name);
if (hostapd_set_iface_flags(drv, 1))
return -1;
@@ -1716,13 +1771,6 @@ static int i802_init(struct hostapd_data
drv->ops = devicescape_driver_ops;
drv->hapd = hapd;
memcpy(drv->iface, hapd->conf->iface, sizeof(drv->iface));
- if (strncmp(hapd->conf->iface, "wlan", 4) == 0) {
- snprintf(drv->mgmt_iface, sizeof(drv->mgmt_iface),
- "wmaster%sap", hapd->conf->iface + 4);
- } else {
- snprintf(drv->mgmt_iface, sizeof(drv->mgmt_iface),
- "%sap", hapd->conf->iface);
- }
if (i802_init_sockets(drv))
goto failed;
@@ -1751,6 +1799,9 @@ static void i802_deinit(void *priv)
(void) hostapd_set_iface_flags(drv, 0);
+ /* Disable management interface */
+ hostap_ioctl_prism2param(drv, PRISM2_PARAM_MGMT_IF, 0);
+
if (drv->sock >= 0)
close(drv->sock);
if (drv->ioctl_sock >= 0)
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: [IPROUTE 01/05]: Use tc_calc_xmittime where appropriate
From: Patrick McHardy @ 2006-06-23 18:28 UTC (permalink / raw)
To: shemminger; +Cc: netdev, hadi
In-Reply-To: <20060623180644.13183.98204.sendpatchset@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 966 bytes --]
Patrick McHardy wrote:
> [IPROUTE]: Use tc_calc_xmittime where appropriate
>
> diff --git a/tc/q_tbf.c b/tc/q_tbf.c
> index 6ed5e0b..87b1b29 100644
> --- a/tc/q_tbf.c
> +++ b/tc/q_tbf.c
> @@ -245,9 +245,9 @@ static int tbf_print_opt(struct qdisc_ut
> if (show_raw)
> fprintf(f, "limit %s ", sprint_size(qopt->limit, b1));
>
> - latency = 1000000*(qopt->limit/(double)qopt->rate.rate) - tc_core_tick2usec(qopt->buffer);
> + latency = tc_calc_xmittime(qopt->rate.rate, qopt->limit) - tc_core_tick2usec(qopt->buffer);
> if (qopt->peakrate.rate) {
> - double lat2 = 1000000*(qopt->limit/(double)qopt->peakrate.rate) - tc_core_tick2usec(qopt->mtu);
> + double lat2 = tc_calc_xmittime(qopt->peakrate.rate, qopt->limit) - tc_core_tick2usec(qopt->mtu);
> if (lat2 > latency)
I think I should start reviewing my own patches in a mail client :)
The two cases above are wrong, tc_calc_xmittime does an additional
tc_core_usec2tick(). Corrected patch attached.
[-- Attachment #2: 01.diff --]
[-- Type: text/plain, Size: 2034 bytes --]
[IPROUTE]: Use tc_calc_xmittime where appropriate
Replace expressions of the form "1000000 * size/rate" by tc_calc_xmittime().
The CBQ case deserves an extra comment: when called with bnwd=rate
tc_cbq_calc_maxidle behaves identical to tc_calc_xmittime, so use it
for clarity.
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit c25b0a7730d72f266e46fee3cfd53ce9f2a15c2f
tree 39c6fbd3395e8a41170739d6cff8d3a00d31a915
parent 8f8a36487119a3cd1afe86a9649704aca088567b
author Patrick McHardy <kaber@trash.net> Fri, 23 Jun 2006 19:02:46 +0200
committer Patrick McHardy <kaber@trash.net> Fri, 23 Jun 2006 19:02:46 +0200
tc/q_cbq.c | 2 +-
tc/q_tbf.c | 4 ++--
tc/tc_core.c | 2 +-
tc/tc_red.c | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/tc/q_cbq.c b/tc/q_cbq.c
index a456eda..045c377 100644
--- a/tc/q_cbq.c
+++ b/tc/q_cbq.c
@@ -147,7 +147,7 @@ static int cbq_parse_opt(struct qdisc_ut
if (ewma_log < 0)
ewma_log = TC_CBQ_DEF_EWMA;
lss.ewma_log = ewma_log;
- lss.maxidle = tc_cbq_calc_maxidle(r.rate, r.rate, avpkt, lss.ewma_log, 0);
+ lss.maxidle = tc_calc_xmittime(r.rate, avpkt);
lss.change = TCF_CBQ_LSS_MAXIDLE|TCF_CBQ_LSS_EWMA|TCF_CBQ_LSS_AVPKT;
lss.avpkt = avpkt;
diff --git a/tc/tc_core.c b/tc/tc_core.c
index 07cf2fa..8688b63 100644
--- a/tc/tc_core.c
+++ b/tc/tc_core.c
@@ -67,7 +67,7 @@ int tc_calc_rtable(unsigned bps, __u32 *
sz += overhead;
if (sz < mpu)
sz = mpu;
- rtab[i] = tc_core_usec2tick(1000000*((double)sz/bps));
+ rtab[i] = tc_calc_xmittime(bps, sz);
}
return cell_log;
}
diff --git a/tc/tc_red.c b/tc/tc_red.c
index 385e7af..8f9bde0 100644
--- a/tc/tc_red.c
+++ b/tc/tc_red.c
@@ -71,7 +71,7 @@ int tc_red_eval_ewma(unsigned qmin, unsi
int tc_red_eval_idle_damping(int Wlog, unsigned avpkt, unsigned bps, __u8 *sbuf)
{
- double xmit_time = tc_core_usec2tick(1000000*(double)avpkt/bps);
+ double xmit_time = tc_calc_xmittime(bps, avpkt);
double lW = -log(1.0 - 1.0/(1<<Wlog))/xmit_time;
double maxtime = 31/lW;
int clog;
^ permalink raw reply related
* Re: [PATCH] 2.6.17 missing a call to ieee80211softmac_capabilities from ieee80211softmac_assoc_req
From: Luis R. Rodriguez @ 2006-06-23 18:38 UTC (permalink / raw)
To: Larry Finger; +Cc: netdev, John Linville
In-Reply-To: <449803E6.5020404@lwfinger.net>
This fixes Assoc with Cisco Aironet 1200 series Wireless Access Points
as well. Tested with zd1211. Without this the zd1211 was not able to
complete assoc. Nice catch.
Luis
On 6/20/06, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> In commit ba9b28d19a3251bb1dfe6a6f8cc89b96fb85f683, routine ieee80211softmac_capabilities was added
> to net/ieee80211/softmac/ieee80211softmac_io.c. As denoted by its name, it completes the
> capabilities IE that is needed in the associate and reassociate requests sent to the AP. For at
> least one AP, the Linksys WRT54G V5, the capabilities field must set the 'short preamble' bit or the
> AP refuses to associate. In the commit noted above, there is a call to the new routine from
> ieee80211softmac_reassoc_req, but not from ieee80211softmac_assoc_req. This patch fixes that oversight.
>
> As noted in the subject, v2.6.17 is affected. My bcm43xx card had been unable to associate since I
> was forced to buy a new AP. I finally was able to get a packet dump and traced the problem to the
> capabilities info. Although I had heard that a patch was "floating around", I had not seen it before
> 2.6.17 was released. As this bug does not affect security and I seem to have the only AP affected by
> it, there should be no problem in leaving it for 2.6.18.
>
> Signed-Off-By: Larry Finger <Larry.Finger@lwfinger.net>
>
> index 0954161..8cc8b20 100644
> --- a/net/ieee80211/softmac/ieee80211softmac_io.c
> +++ b/net/ieee80211/softmac/ieee80211softmac_io.c
> @@ -229,6 +229,9 @@ ieee80211softmac_assoc_req(struct ieee8
> return 0;
> ieee80211softmac_hdr_3addr(mac, &((*pkt)->header), IEEE80211_STYPE_ASSOC_REQ, net->bssid, net->bssid);
>
> + /* Fill in the capabilities */
> + (*pkt)->capability = ieee80211softmac_capabilities(mac, net);
> +
> /* Fill in Listen Interval (?) */
> (*pkt)->listen_interval = cpu_to_le16(10);
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [1/4] kevent: core files.
From: Benjamin LaHaise @ 2006-06-23 18:44 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: David Miller, netdev
In-Reply-To: <20060623070933.GA20291@2ka.mipt.ru>
On Fri, Jun 23, 2006 at 11:09:34AM +0400, Evgeniy Polyakov wrote:
> This patch includes core kevent files:
> - userspace controlling
> - kernelspace interfaces
> - initialisation
> - notification state machines
We don't need yet another event mechanism in the kernel, so I don't see
why the new syscalls should be added when they don't interoperate with
existing solutions. If your results are enough to sway akpm that it is
worth taking the patches, then it would make sense to merge the code with
the already in-tree APIs.
-ben
^ permalink raw reply
* Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
From: Ivo van Doorn @ 2006-06-23 18:51 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: Jiri Benc, Stefan Rompf, Francois Romieu, netdev
In-Reply-To: <20060623110819.GA29574@suse.cz>
[-- Attachment #1: Type: text/plain, Size: 3088 bytes --]
Hi,
> > On Sat, 17 Jun 2006 17:05:55 +0200, Ivo van Doorn wrote:
> > > With this approach more buttons can be registered,
> > > it includes the optional field to report an update of the key status
> > > to the driver that registered it, and it supports for non-polling keys.
> >
> > I think this is not specific to networking anymore, so it should go to
> > lkml. Please be sure to Cc: input devices maintainer, Dmitry Torokhov.
> >
> > Regarding rfkill button, I talked about that with Vojtech Pavlik (Cc:ed)
> > and he suggests this solution:
> >
> > - driver is responsible for turning on/off radio when the input device
> > is not opened;
> > - when something opens the input device, it receives input events and
> > gets responsible to turn on/off the radio (by ioctl or putting the
> > network interfaces up/down).
> >
> > This is of course not possible for all hardware, but it gives the most
> > flexibility while keeping the possibility to switch of the radio without
> > userspace support.
>
> Let me elaborate a little bit on the possible implementation:
>
> 1) 802.11 card drivers will implement an input device for each card in
> the system that has a user-controlled RF-Kill button or switch.
So basicly 1 input device for every single wireless driver that implements
the RF-Kill button?
Is there any particular reason for not using 1 input device shared by all?
> 2) 802.11 card drivers will implement an interface to enable/disable the
> radio, be it through a call, ioctl, or whatever, that is accessible from
> both the kernel and userspace.
Userspace could switch off the radio by using the txpower ioctl of
ifdown/ifup. Or should an approach call be implemented?
> 3) ACPI buttons drivers, and keyboard drivers will generate KEY_RFKILL
> on machines where RF-Kill keys are reported using ACPI events or
> keyboard scancodes.
Why both an input and ACPI event?
With ACPI restricted to x86 only, wouldn't a more generic approach be desired?
> 3) A rfkill.ko input handler module will be implemented, that listens to
> the SW_RFKILL and KEY_RFKILL events from all devices in the system, and
> will enable/disable radios on all 802.11 devices in the system.
>
> The above will make the RF-Kill button work under all real scenarios as
> user expects - it will enable/disable the radio. In the case where a
> user has an additional PCMCIA card, both the radios will be disabled by
> presing the RF-Kill button, which is arguably what the user expects.
> Even BlueTooth or other RF technologies (CDMA, EDGE) can hook into this
> mechanism.
>
> 4) When userspace wants to take over the control over RF-Kill, and start
> additional services based on that, it can open the input devices to get
> the state of the buttons/switches, AND it can issue the EVIOCGRAB
> ioctl() to prevent the rfkill.ko and any other handlers from getting the
> events.
>
> This allows simple implementation of dbus notifications and
> NetworkManager-style configuration of network interfaces.
>
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC 3/7] NetLabel: CIPSOv4 engine
From: Ted @ 2006-06-23 18:48 UTC (permalink / raw)
To: netdev
In-Reply-To: <20060622.021223.125894633.davem@davemloft.net>
On Thu, 2006-06-22 at 02:12 -0700, David Miller wrote:
> From: paul.moore@hp.com
> Date: Wed, 21 Jun 2006 15:42:38 -0400
>
> > Add support for the Commercial IP Security Option (CIPSO) to the
> > IPv4 network stack. CIPSO has become a de-facto standard for
> > trusted/labeled networking amongst existing Trusted Operating
> > Systems such as Trusted Solaris, HP-UX CMW, etc. This
> > implementation is designed to be used with the NetLabel subsystem to
> > provide explicit packet labeling to LSM developers.
>
> The thing that concerns me most about CIPSO is that even once users
> migrate to a more SELINUX native approach from this CIPSO stuff, the
> CIPSO code, it's bloat, and it's maintainence burdon will remain.
>
> It's easy to put stuff it, it's impossible to take stuff out even
> once it's largely unused by even it's original target audience.
>
> And that's what I see happening here.
>
> This is why, to be perfectly honest with you, I'd much rather
> something like this stay out-of-tree and people are strongly
> encouraged to use the more native stuff under Linux.
>
Realistically customers most likely to adopt use of SELinux are going to
be ones that currently use other trusted OSs such as TSOL and HP-UX CMW.
These users are unlikely to take an all (SELinux) or nothing approach.
Also they are more than likely customers who will want a fully
configured and supported distribution as opposed to one they'd have to
patch themselves. With these points in mind I think CIPSO as a
integrated interoperability mechanism is critical. FYI, over the last
couple of weeks I've validated the interoperability of the CIPSO
inplementation with TSOL and HP-UX CMW.
Ted
> --
> redhat-lspp mailing list
> redhat-lspp@redhat.com
> https://www.redhat.com/mailman/listinfo/redhat-lspp
^ permalink raw reply
* Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
From: Ivo van Doorn @ 2006-06-23 18:53 UTC (permalink / raw)
To: Jiri Benc; +Cc: Stefan Rompf, Francois Romieu, netdev, Vojtech Pavlik
In-Reply-To: <20060622175546.7eebebb4@griffin.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 762 bytes --]
On Thursday 22 June 2006 17:55, Jiri Benc wrote:
> On Sat, 17 Jun 2006 17:05:55 +0200, Ivo van Doorn wrote:
> > With this approach more buttons can be registered,
> > it includes the optional field to report an update of the key status
> > to the driver that registered it, and it supports for non-polling keys.
>
> I think this is not specific to networking anymore, so it should go to
> lkml. Please be sure to Cc: input devices maintainer, Dmitry Torokhov.
Thanks, I am currently discussing the driver with developers
from button drivers like acerhk and acpi_acer.
If I am sending the driver to the lkml will depend on their
reaction and input for the driver. No use sending drivers to
lkml when no other driver will want to use it. ;)
Ivo
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [1/4] kevent: core files.
From: Evgeniy Polyakov @ 2006-06-23 19:24 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: David Miller, netdev
In-Reply-To: <20060623184457.GA13617@kvack.org>
On Fri, Jun 23, 2006 at 02:44:57PM -0400, Benjamin LaHaise (bcrl@kvack.org) wrote:
> On Fri, Jun 23, 2006 at 11:09:34AM +0400, Evgeniy Polyakov wrote:
> > This patch includes core kevent files:
> > - userspace controlling
> > - kernelspace interfaces
> > - initialisation
> > - notification state machines
>
> We don't need yet another event mechanism in the kernel, so I don't see
> why the new syscalls should be added when they don't interoperate with
> existing solutions. If your results are enough to sway akpm that it is
> worth taking the patches, then it would make sense to merge the code with
> the already in-tree APIs.
What API are you talking about?
There is only epoll(), which is 40% slower than kevent, and AIO, which
works not as state machine, but as repeated call for the same work.
There is also inotify, which allocates new message each time event
occurs, which is not a good solution for every situation.
Linux just does not have unified event processing mechanism, which was
pointed to many times in AIO mail list and when epoll() was only
introduced. I would even say, that Linux does not have such mechanism at
all, since every potential user implements it's own, which can not be
used with others.
Kevent fixes that. Although implementation itself can be suboptimal for
some cases or even unacceptible at all, but it is really needed
functionality.
Every existing notification can be built on top of kevent. One can find
how easy it was to implement generic poll/select notifications (what
epoll() does) or socket notifications (which are similar to epoll(), but
are called from inside socket state machine, thus improving processing
performance).
> -ben
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [3/5] [NET]: Add software TSOv4
From: Michael Chan @ 2006-06-23 19:33 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, netdev
In-Reply-To: <20060622081400.GC22671@gondor.apana.org.au>
On Thu, 2006-06-22 at 18:14 +1000, Herbert Xu wrote:
> [NET]: Add software TSOv4
>
> This patch adds the GSO implementation for IPv4 TCP.
Herbert, Looks like there were some problems in the CHECKSUM_HW case.
This patch should fix it. Please double-check my checksum math.
[NET]: Fix CHECKSUM_HW GSO problems.
Fix the following 2 problems in the GSO code path for CHECKSUM_HW
packets:
1. Adjust ipv4 TCP pseudo header checksum.
2. Initialize skb->tail.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 8e5044b..3f19b3d 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -1954,6 +1954,7 @@ struct sk_buff *skb_segment(struct sk_bu
nskb->data_len = len - hsize;
nskb->len += nskb->data_len;
nskb->truesize += nskb->data_len;
+ nskb->tail += nskb->data_len;
} while ((offset += len) < skb->len);
return segs;
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 0e029c4..3399110 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2186,7 +2186,8 @@ struct sk_buff *tcp_tso_segment(struct s
if (skb->ip_summed == CHECKSUM_NONE) {
th->check = csum_fold(csum_partial(
skb->h.raw, thlen, csum_add(skb->csum, delta)));
- }
+ } else if (skb->ip_summed == CHECKSUM_HW)
+ th->check = ~csum_fold(csum_add(th->check, delta));
seq += len;
skb = skb->next;
@@ -2196,11 +2197,12 @@ struct sk_buff *tcp_tso_segment(struct s
th->cwr = 0;
} while (skb->next);
+ delta = csum_add(oldlen, htonl(skb->tail - skb->h.raw));
if (skb->ip_summed == CHECKSUM_NONE) {
- delta = csum_add(oldlen, htonl(skb->tail - skb->h.raw));
th->check = csum_fold(csum_partial(
skb->h.raw, thlen, csum_add(skb->csum, delta)));
- }
+ } else if (skb->ip_summed == CHECKSUM_HW)
+ th->check = ~csum_fold(csum_add(th->check, delta));
out:
return segs;
^ permalink raw reply related
* Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
From: Vojtech Pavlik @ 2006-06-23 19:32 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: Jiri Benc, Stefan Rompf, Francois Romieu, netdev
In-Reply-To: <200606232051.37518.IvDoorn@gmail.com>
On Fri, Jun 23, 2006 at 08:51:33PM +0200, Ivo van Doorn wrote:
> > > This is of course not possible for all hardware, but it gives the most
> > > flexibility while keeping the possibility to switch of the radio without
> > > userspace support.
> >
> > Let me elaborate a little bit on the possible implementation:
> >
> > 1) 802.11 card drivers will implement an input device for each card in
> > the system that has a user-controlled RF-Kill button or switch.
>
> So basicly 1 input device for every single wireless driver that implements
> the RF-Kill button?
Yes.
> Is there any particular reason for not using 1 input device shared by all?
Yes.
In the unlikely case where there are two devices which implement a
rfkill button in the system, the input core doesn't have a way how to
express the state of these two different buttons with the same meaning
(and hence the same code - KEY_RFKILL) in a single input device.
You'd have to assign a range of codes to the shared device, which goes
agains the design of the Linux inpu layer.
Anyway, for the most common case, where you have a single RF-Kill key in
the whole system, there will not be any difference to using the shared
device.
What do you consider the benefits of using a shared input device?
> > 2) 802.11 card drivers will implement an interface to enable/disable the
> > radio, be it through a call, ioctl, or whatever, that is accessible from
> > both the kernel and userspace.
>
> Userspace could switch off the radio by using the txpower ioctl of
> ifdown/ifup. Or should an approach call be implemented?
I'm an input guy, the details of how to disable the radio I'll leave up
to you - the WiFi folks on netdev.
You may want to consider that the radio chip usually synthesizes a
frequency that it mixes with the incoming signal to frequency-shift it
to a low frequency which then can be demodulated. Because of that, even
the receiver, when working, can affect devices nearby. This is why FM
radio receivers are not allowed on airplanes.
Hardware RF-Kill disables both RX and TX, by stopping the radio chip.
Setting TX power to an extremely low value might not be the same.
On the other hand, you may define in the API that setting TX power to
zero also disables the receiver.
> > 3) ACPI buttons drivers, and keyboard drivers will generate KEY_RFKILL
> > on machines where RF-Kill keys are reported using ACPI events or
> > keyboard scancodes.
>
> Why both an input and ACPI event?
> With ACPI restricted to x86 only, wouldn't a more generic approach be desired?
I was talking about the ACPI EC sending us an event. This is how are
ACPI buttons implemented in certain notebooks. I definitely don't want
to use the acpi events as received by acpid now as the interface. Sorry
for the confusion.
> > 3) A rfkill.ko input handler module will be implemented, that listens to
> > the SW_RFKILL and KEY_RFKILL events from all devices in the system, and
> > will enable/disable radios on all 802.11 devices in the system.
> >
> > The above will make the RF-Kill button work under all real scenarios as
> > user expects - it will enable/disable the radio. In the case where a
> > user has an additional PCMCIA card, both the radios will be disabled by
> > presing the RF-Kill button, which is arguably what the user expects.
> > Even BlueTooth or other RF technologies (CDMA, EDGE) can hook into this
> > mechanism.
> >
> > 4) When userspace wants to take over the control over RF-Kill, and start
> > additional services based on that, it can open the input devices to get
> > the state of the buttons/switches, AND it can issue the EVIOCGRAB
> > ioctl() to prevent the rfkill.ko and any other handlers from getting the
> > events.
> >
> > This allows simple implementation of dbus notifications and
> > NetworkManager-style configuration of network interfaces.
--
Vojtech Pavlik
Director SuSE Labs
^ permalink raw reply
* Re: System hangs after running 2.6.17rc6 with broadcom 4309 and device scape stack
From: Alex Davis @ 2006-06-23 19:38 UTC (permalink / raw)
To: Jiri Benc; +Cc: netdev
In-Reply-To: <20060623141325.0de4970e@griffin.suse.cz>
--- Jiri Benc <jbenc@suse.cz> wrote:
> On Sun, 18 Jun 2006 18:25:54 -0700 (PDT), Alex Davis wrote:
> > Here is dmesg output for module loading.
> > [...]
> > Jun 16 20:04:06 siafu kernel: [4294720.505000] bcm43xx_d80211: Virtual interface added (type:
> > 0x00000002, ID: 4, MAC: 00:90:96:ba:32:20)
> > Jun 16 20:04:06 siafu kernel: [4294720.511000] bcm43xx_d80211: PHY connected
> > Jun 16 20:04:07 siafu kernel: [4294720.779000] bcm43xx_d80211: Radio turned on
> > Jun 16 20:04:07 siafu kernel: [4294720.971000] bcm43xx_d80211: Chip initialized
> > Jun 16 20:04:07 siafu kernel: [4294720.972000] bcm43xx_d80211: DMA initialized
> > Jun 16 20:04:07 siafu kernel: [4294720.972000] bcm43xx_d80211: 80211 cores initialized
> > Jun 16 20:04:07 siafu kernel: [4294720.972000] bcm43xx_d80211: Keys cleared
> > Jun 16 20:04:07 siafu kernel: [4294720.988000] wmaster0: Does not support passive scan,
> disabled
> > Jun 16 20:04:09 siafu kernel: [4294723.027000] bcm43xx_d80211: ASSERTION FAILED
> > (bcm->interface.if_id == if_id) at:
> > drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c:4344:bcm43xx_config_interface()
>
> This is really strange. Is this reproducible with latest wireless-dev?
I was using the latest: John Linville's git development release (2.6.17rc6).
I cloned it from git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git
on 6/15/2006 21:00 EDT. As of today (6/23), there have been no changes.
> There was ifconfig up (or similar) command at 20:04:06 but
> wpa_supplicant was started at 20:04:14. What happened in-between?
Nothing. I start everything up by hand, hence the delay.
I use the following commands:
modprobe bcm43xx-d80211
wpa_supplicant -i wlan0 ....
dmesg # to make sure I'm associated with the access point, and see any debugging info.
dhcpcd wlan0
ping ....
login as non-root user and start x.
> Most important, what happened between 20:04:07 and 20:04:09? (I.e. what
> commands were invoked?)
No commands were invoked during that period.
I'm currently using the rc5 version with no problems.
> Thanks,
>
> Jiri
>
> --
> Jiri Benc
> SUSE Labs
>
I code, therefore I am
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Just out Professional Degrees in 2 Weeks
From: Vera @ 2006-06-23 18:43 UTC (permalink / raw)
To: nicknetwfpog
More earning power
Fas t Tra ck Deg ree Progra m
Obtain the d egree you deserve, based on your present knowledge and life
experience. A prosperous future, money earning power, and the Admiration of all.
Degre es from an Established, Pres tigious, Leading Institution.
Your degr ee will show exactly what you really can do.
Get the Job, Promotion, Business Opportunity and Social Advancement you Desire!
Eliminates classrooms and traveling.
Achieve your Bachelor s, Mast ers, M BA, or Ph D
in the field of your expertise.
Professional and affordable! Call now - your Gradua tion is a phone call away.
Please call:
1-206-600-68 25
Calls returned promptly
Two things a man should never be angry at: what he can help and what he cannot help Man cannot live on bread alone Life is beautiful One foolish sheep will lead the flock When he speaketh fair, believe him not: for there are seven abominations in his heart. Better bend than break Because I have called, and ye refused; I have stretched out my hand, and no man regarded.
^ permalink raw reply
* Re: [1/4] kevent: core files.
From: Benjamin LaHaise @ 2006-06-23 19:55 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: David Miller, netdev
In-Reply-To: <20060623192422.GA11508@2ka.mipt.ru>
On Fri, Jun 23, 2006 at 11:24:29PM +0400, Evgeniy Polyakov wrote:
> What API are you talking about?
> There is only epoll(), which is 40% slower than kevent, and AIO, which
> works not as state machine, but as repeated call for the same work.
> There is also inotify, which allocates new message each time event
> occurs, which is not a good solution for every situation.
AIO can be implemented as a state machine. Nothing in the API stops
you from doing that, and in fact there was code which was implemented as
a state machine used on 2.4 kernels.
> Linux just does not have unified event processing mechanism, which was
> pointed to many times in AIO mail list and when epoll() was only
> introduced. I would even say, that Linux does not have such mechanism at
> all, since every potential user implements it's own, which can not be
> used with others.
The epoll event API doesn't have space in the event fields for result codes
as needed for AIO. The AIO API does -- how is it lacking in this regard?
> Kevent fixes that. Although implementation itself can be suboptimal for
> some cases or even unacceptible at all, but it is really needed
> functionality.
At the expense of adding another API? How is this a good thing? Why
not spit out events in the existing format?
> Every existing notification can be built on top of kevent. One can find
> how easy it was to implement generic poll/select notifications (what
> epoll() does) or socket notifications (which are similar to epoll(), but
> are called from inside socket state machine, thus improving processing
> performance).
So far your code is adding a lot without unifying anything.
-ben
--
"Time is of no importance, Mr. President, only life is important."
Don't Email: <dont@kvack.org>.
^ permalink raw reply
* Re: [PATCH 0/2][RFC] Network Event Notifier Mechanism
From: David Miller @ 2006-06-23 19:57 UTC (permalink / raw)
To: swise; +Cc: hadi, netdev, caitlinb
In-Reply-To: <1151069083.7808.19.camel@stevo-desktop>
From: Steve Wise <swise@opengridcomputing.com>
Date: Fri, 23 Jun 2006 08:24:43 -0500
> On Thu, 2006-06-22 at 20:56 -0400, jamal wrote:
> > On Thu, 2006-22-06 at 15:58 -0700, David Miller wrote:
> >
> > > Anyways, we can create normal notifiers for neighbour and route
> > > events just like we have for network device stuff.
> > >
>
> So did you agree with a new notifier head for these events as in my
> original patch? Or do you think I should add these to the netdev
> notifier?
Pretty much. I may not agree with the details of your implementation.
So let's start by you doing a repost of the first patch and let's
review that, ok?
^ permalink raw reply
* Re: [RFC IPROUTE 00/05]: Time cleanups
From: David Miller @ 2006-06-23 20:01 UTC (permalink / raw)
To: kaber; +Cc: shemminger, netdev, hadi
In-Reply-To: <449C2E4E.7050301@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Fri, 23 Jun 2006 20:09:18 +0200
> D'oh, got Stephen's address wrong. Please fix it (add 's' in front) in
> replies to this thread.
Stephen's also on vacation for a week, so it might be a while
until this stuff is integrated :)
^ permalink raw reply
* Re: [PATCH]: e1000: Janitor: Use #defined values for literals
From: Auke Kok @ 2006-06-23 20:07 UTC (permalink / raw)
To: Linas Vepstas
Cc: netdev, john.ronciak, jesse.brandeburg, jeffrey.t.kirsher,
Zhang, Yanmin, Jeff Garzik, linux-kernel
In-Reply-To: <20060623163624.GM8866@austin.ibm.com>
Linas Vepstas wrote:
> Minor janitorial patch: use #defines for literal values.
>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
>
> ----
> drivers/net/e1000/e1000_main.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> Index: linux-2.6.17-rc6-mm2/drivers/net/e1000/e1000_main.c
> ===================================================================
> --- linux-2.6.17-rc6-mm2.orig/drivers/net/e1000/e1000_main.c 2006-06-13 18:13:30.000000000 -0500
> +++ linux-2.6.17-rc6-mm2/drivers/net/e1000/e1000_main.c 2006-06-23 11:27:47.000000000 -0500
> @@ -4663,8 +4663,8 @@ static pci_ers_result_t e1000_io_slot_re
> }
> pci_set_master(pdev);
>
> - pci_enable_wake(pdev, 3, 0);
> - pci_enable_wake(pdev, 4, 0); /* 4 == D3 cold */
> + pci_enable_wake(pdev, PCI_D3hot, 0);
> + pci_enable_wake(pdev, PCI_D3cold, 0);
>
> /* Perform card reset only on one instance of the card */
> if (PCI_FUNC (pdev->devfn) != 0)
I Acked this but that's silly - the patches sent yesterday already change the
code above and this patch is no longer needed (thanks Jesse for spotting this).
This patch would conflict with them so please don't apply.
Cheers,
AUke
^ permalink raw reply
* Re: [PATCH 0/2][RFC] Network Event Notifier Mechanism
From: Steve Wise @ 2006-06-23 20:12 UTC (permalink / raw)
To: David Miller; +Cc: hadi, netdev, caitlinb
In-Reply-To: <20060623.125758.30182159.davem@davemloft.net>
On Fri, 2006-06-23 at 12:57 -0700, David Miller wrote:
> From: Steve Wise <swise@opengridcomputing.com>
> Date: Fri, 23 Jun 2006 08:24:43 -0500
>
> > On Thu, 2006-06-22 at 20:56 -0400, jamal wrote:
> > > On Thu, 2006-22-06 at 15:58 -0700, David Miller wrote:
> > >
> > > > Anyways, we can create normal notifiers for neighbour and route
> > > > events just like we have for network device stuff.
> > > >
> >
> > So did you agree with a new notifier head for these events as in my
> > original patch? Or do you think I should add these to the netdev
> > notifier?
>
> Pretty much. I may not agree with the details of your implementation.
>
> So let's start by you doing a repost of the first patch and let's
> review that, ok?
Ok. Stay tuned.
Steve.
^ permalink raw reply
* Re: [RFC 3/7] NetLabel: CIPSOv4 engine
From: David Miller @ 2006-06-23 20:15 UTC (permalink / raw)
To: txtoth; +Cc: netdev
In-Reply-To: <1151088481.2669.25.camel@localhost.localdomain>
From: Ted <txtoth@gmail.com>
Date: Fri, 23 Jun 2006 13:48:01 -0500
> Realistically customers most likely to adopt use of SELinux are
> going to be ones that currently use other trusted OSs such as TSOL
> and HP-UX CMW.
Every single user who installs a modern distribution these days likely
gets SELINUX enabled by default, and are therefore adopters of
SELINUX. That's a lot of people.
The number of people with existing CIPSO infrastructure are miniscule
in comparison.
Please do not even imply that CIPSO use is anything but fringe in the
grand scheme of things. It most certainly is. And it will be
replaced by IPSEC based labelling, that is a fact. If people cannot
move over to IPSEC labelling simply because their HPUX/TSOL doesn't
support it, I'm perfectly happy for those users to stick with HPUX and
TSOL. A lot of people think Linux should try to be everything for
everybody, I'm not one of those people :-)
For CIPSO we eat a non-trivial maintainence and bloat cost in order to
support legacy stuff for this relatively tiny group of potential
users.
I'd rather pay the bloat and development costs on something forward
thinking like IPSEC labelling. Something people will actually be
using years from now, rather than a dying technology that few people
(relatively speaking) use as it is.
Finally, even if CIPSO is something we want to put in, don't worry
about it as there's still time to discuss things. A couple days
before the merge window of 2.6.18 development closes is not the time
to be submitting half-finished work and expecting it to be integrated.
If 2.6.18 integration is what the submitter desires, they should have
finished their work and started this review process weeks if not
months ago.
^ permalink raw reply
* Re: ixgb EEH/PCI errors on reset
From: Brandeburg, Jesse @ 2006-06-23 20:15 UTC (permalink / raw)
To: Linas Vepstas
Cc: Brandeburg, Jesse, Ronciak, John, cramerj, Kirsher, Jeffrey T,
Kok, Auke-jan H, Veeraiyan, Ayyappan, netdev
In-Reply-To: <20060623170958.GN8866@austin.ibm.com>
On Fri, 23 Jun 2006, Linas Vepstas wrote:
> I've got another ixgb driver bug I'm struggling with; clues or hints
> appreciated.
>
> I've got a patch for PCI error recovery for the ixgb, which works on
> many older kernels but seems to be broken on linux-2.6.17-rc6-mm2
> (which is ixgb version 1.0.109). After performing a PCI reset on the
> card, I try to re-initialize the cad and the driver, with the following
> sequence:
>
> pci_set_master(pdev);
> netif_carrier_off(netdev);
> netif_stop_queue(netdev);
> ixgb_check_options(adapter);
> ixgb_reset(adapter);
>
> This is only a subset of the ixgb_probe code, since I don't need to
> request regions or do any of the other setup. However, this code
> fails in an unexpected way. The last call invokes ixgb_mac_reset()
> which writes a reset bit, delays a few millisecs, and reads the reset
> bit. The problem I'm seeing is that the read
>
> ctrl_reg = IXGB_READ_REG(hw, CTRL0);
>
> triggers some PCI bus error that off-lines the device. Any hints
> about where to look? This doesn't occur on other driver versions,
> and doesn't occur on this driver during the ordinary probe() sequence.
> Increasing the dealy doesn't seem to help.
you probably need to do something similar to stopping the transmitter and
receiver using the TCTL and RCTL registers, and then waiting for any
pending master requests to finish.
Ah, it appears the code in ixgb_adapter_stop is missing a IXGB_WRITE_FLUSH
before the msec_delay.
try this patch? it is compile tested.
<snip>
[PATCH] ixgb: make sure to flush writes before waiting
ixgb is missing some write flushes when issuing the reset, and a few
others for that matter.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
---
drivers/net/ixgb/ixgb_ee.c | 9 +++++++++
drivers/net/ixgb/ixgb_hw.c | 5 +++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_ee.c b/drivers/net/ixgb/ixgb_ee.c
index 8357c55..2359973 100644
--- a/drivers/net/ixgb/ixgb_ee.c
+++ b/drivers/net/ixgb/ixgb_ee.c
@@ -55,6 +55,7 @@ ixgb_raise_clock(struct ixgb_hw *hw,
*/
*eecd_reg = *eecd_reg | IXGB_EECD_SK;
IXGB_WRITE_REG(hw, EECD, *eecd_reg);
+ IXGB_WRITE_FLUSH(hw);
udelay(50);
return;
}
@@ -74,6 +75,7 @@ ixgb_lower_clock(struct ixgb_hw *hw,
*/
*eecd_reg = *eecd_reg & ~IXGB_EECD_SK;
IXGB_WRITE_REG(hw, EECD, *eecd_reg);
+ IXGB_WRITE_FLUSH(hw);
udelay(50);
return;
}
@@ -112,6 +114,7 @@ ixgb_shift_out_bits(struct ixgb_hw *hw,
eecd_reg |= IXGB_EECD_DI;
IXGB_WRITE_REG(hw, EECD, eecd_reg);
+ IXGB_WRITE_FLUSH(hw);
udelay(50);
@@ -208,21 +211,25 @@ ixgb_standby_eeprom(struct ixgb_hw *hw)
/* Deselct EEPROM */
eecd_reg &= ~(IXGB_EECD_CS | IXGB_EECD_SK);
IXGB_WRITE_REG(hw, EECD, eecd_reg);
+ IXGB_WRITE_FLUSH(hw);
udelay(50);
/* Clock high */
eecd_reg |= IXGB_EECD_SK;
IXGB_WRITE_REG(hw, EECD, eecd_reg);
+ IXGB_WRITE_FLUSH(hw);
udelay(50);
/* Select EEPROM */
eecd_reg |= IXGB_EECD_CS;
IXGB_WRITE_REG(hw, EECD, eecd_reg);
+ IXGB_WRITE_FLUSH(hw);
udelay(50);
/* Clock low */
eecd_reg &= ~IXGB_EECD_SK;
IXGB_WRITE_REG(hw, EECD, eecd_reg);
+ IXGB_WRITE_FLUSH(hw);
udelay(50);
return;
}
@@ -242,11 +249,13 @@ ixgb_clock_eeprom(struct ixgb_hw *hw)
/* Rising edge of clock */
eecd_reg |= IXGB_EECD_SK;
IXGB_WRITE_REG(hw, EECD, eecd_reg);
+ IXGB_WRITE_FLUSH(hw);
udelay(50);
/* Falling edge of clock */
eecd_reg &= ~IXGB_EECD_SK;
IXGB_WRITE_REG(hw, EECD, eecd_reg);
+ IXGB_WRITE_FLUSH(hw);
udelay(50);
return;
}
diff --git a/drivers/net/ixgb/ixgb_hw.c b/drivers/net/ixgb/ixgb_hw.c
index f7fa10e..3e08ba8 100644
--- a/drivers/net/ixgb/ixgb_hw.c
+++ b/drivers/net/ixgb/ixgb_hw.c
@@ -81,7 +81,7 @@ static uint32_t ixgb_mac_reset(struct ix
#else
IXGB_WRITE_REG(hw, CTRL0, ctrl_reg);
#endif
-
+ IXGB_WRITE_FLUSH(hw);
/* Delay a few ms just to allow the reset to complete */
msec_delay(IXGB_DELAY_AFTER_RESET);
ctrl_reg = IXGB_READ_REG(hw, CTRL0);
@@ -133,6 +133,7 @@ ixgb_adapter_stop(struct ixgb_hw *hw)
*/
IXGB_WRITE_REG(hw, RCTL, IXGB_READ_REG(hw, RCTL) & ~IXGB_RCTL_RXEN);
IXGB_WRITE_REG(hw, TCTL, IXGB_READ_REG(hw, TCTL) & ~IXGB_TCTL_TXEN);
+ IXGB_WRITE_FLUSH(hw);
msec_delay(IXGB_DELAY_BEFORE_RESET);
/* Issue a global reset to the MAC. This will reset the chip's
@@ -287,7 +288,7 @@ ixgb_init_hw(struct ixgb_hw *hw)
#else
IXGB_WRITE_REG(hw, CTRL1, IXGB_CTRL1_EE_RST);
#endif
-
+ IXGB_WRITE_FLUSH(hw);
/* Delay a few ms just to allow the reset to complete */
msec_delay(IXGB_DELAY_AFTER_EE_RESET);
^ permalink raw reply related
* Re: [1/4] kevent: core files.
From: Evgeniy Polyakov @ 2006-06-23 20:17 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: David Miller, netdev
In-Reply-To: <20060623195513.GC14126@kvack.org>
On Fri, Jun 23, 2006 at 03:55:13PM -0400, Benjamin LaHaise (bcrl@kvack.org) wrote:
> On Fri, Jun 23, 2006 at 11:24:29PM +0400, Evgeniy Polyakov wrote:
> > What API are you talking about?
> > There is only epoll(), which is 40% slower than kevent, and AIO, which
> > works not as state machine, but as repeated call for the same work.
> > There is also inotify, which allocates new message each time event
> > occurs, which is not a good solution for every situation.
>
> AIO can be implemented as a state machine. Nothing in the API stops
> you from doing that, and in fact there was code which was implemented as
> a state machine used on 2.4 kernels.
But now it is implemented as repeated call for the same work, which does
not look like it can be used for any other types of work.
And repeated work introduce latencies.
As far as I recall, it is you who wanted to remove thread based approach
from AIO subsystem.
> > Linux just does not have unified event processing mechanism, which was
> > pointed to many times in AIO mail list and when epoll() was only
> > introduced. I would even say, that Linux does not have such mechanism at
> > all, since every potential user implements it's own, which can not be
> > used with others.
>
> The epoll event API doesn't have space in the event fields for result codes
> as needed for AIO. The AIO API does -- how is it lacking in this regard?
AIO completion approach was designed to be used with process context VFS
update. read/write approach can not cover other types of notifications,
like inode updates or timers.
> > Kevent fixes that. Although implementation itself can be suboptimal for
> > some cases or even unacceptible at all, but it is really needed
> > functionality.
>
> At the expense of adding another API? How is this a good thing? Why
> not spit out events in the existing format?
Format of the structure transferred between the objects does not matter
at all. We can create a wrapper on kevent structures or kevent can
transform data from AIO objects.
The main design goal of kevent is to provide easy connected hooks into
any state machine, which might be used by kernelspace to notify about
any kind of events without any knowledge of it's background nature.
Kevent can be used for example as notification blocks for address
changes or it can replace netlink completely (it can even emulate
event multicasting).
Kevent is queue of events, which can be transferred from any object to
any destination.
> > Every existing notification can be built on top of kevent. One can find
> > how easy it was to implement generic poll/select notifications (what
> > epoll() does) or socket notifications (which are similar to epoll(), but
> > are called from inside socket state machine, thus improving processing
> > performance).
>
> So far your code is adding a lot without unifying anything.
Not at all!
Kevent is a mechanism, which allows to impleement AIO, network AIO, poll
and select, timer control, adaptive readhead (as example of AIO VFS
update). All the code I present shows how to use kevent, it is not part
of the kevent. One can find Makefile in kevent dir to check what is the
core of the subsystem, which allows to be used as a transport for
events.
AIO, NAIO, poll/select, socket and timer notifications are just users.
One can add it's own usage as easy as to call kevent_storage
initialization function and event generation function. All other pieces
are hidded in the implementation.
> -ben
> --
> "Time is of no importance, Mr. President, only life is important."
> Don't Email: <dont@kvack.org>.
--
Evgeniy Polyakov
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox