Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
On Tue, 24 Oct 2006 13:41:12 -0400, Luis R. Rodriguez wrote: Sure -- we can have on the ieee80211_conf struct an array of all regulatory domains stack values that the device supports (REGDOMAIN_FCC or 0x10 for FCC for example) if the developer agrees the device has been certified to match the regulatory domain restrictions as the stack defines it. I believe most modern devices adhere to the PtMP restrictions pretty loosely and the magic is left to the driver when the device is being certified so ultimately I see devices sharing regulatory domains restrictions rather than defining their own though. I'd consider defining your own device-specific regulatory domain would be more of an exception we'd have to deal with but that remains to be seen yet huh. It sounds overcomplicated to me. I'd rather like to see something like this: 1. As part of the initialization of the hardware, the driver detects that the device is certified for (say) channels 2 to 10 (that's not a real-life example, fortunately :-)). 2. The driver reports this somewhere (softmac drivers would report this to the stack). 3. Based on outside conditions (userspace - or something - tells us about actual regdomain), the stack (or whatever) calls the driver and passes allowed channels etc. to it (if the driver wants that information). There is already previously reported driver's limitation taken in the account in that information. 4. If the outside conditions change (802.11d or user emigrates or something) that callback is called again with a new data. I.e.: - I see no point in building a list of regdomains suported by the hardware. - It's pretty common that the device has some limitation stated in the EPROM and the stack/something should deal with it in a way that is easy to use in a driver. Thanks, Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/2]d80211: hardware TKIP support for ipw3945
On Tue, 2006-10-24 at 17:10, Johannes Berg wrote:
On Tue, 2006-10-24 at 16:38 +0800, Hong Liu wrote:
The first time when we set the TKIP key, we can set the phase1 key if
the driver requires.
Right.
The problem is when IV16 wraps, who will generate the new phase1 key?
Ok, I was confused for a moment, but yes, when the 16-bit part of the IV
wraps then the upper part changes and hence you need to regenerate the
phase1 key.
If the stack need to do this, then we will need to call set_key in the
packet TX path which I think may not be appropriate.
Well, I checked again and found that bcm34xx requires the IV (48) to be
maintained by software, iow with each packet you tell the hardware what
the IV16 should be. Hence you know when it has wrapped and thus (before
submitting the DMA for the packet) you can regenerate the phase1 key in
software and upload it to the hardware key memory.
This is getting quite complicated. How about having the stack maintain
the IV *only*, and adding helper functions for
* generating the phase 1 key
* generating the phase 2 key based on the phase 1 key
that the drivers can use as required?
ipw3945 would call both key generation functions as required, and
bcm43xx would just call the phase 1 function when a key is uploaded and
when the iv16 wraps, not using the phase 2 function at all.
johannes
I'd prefer to let the stack tell the driver when there is new phase1 key
generated.
Rebase the patch on David Kimdon's bitfield removing patches.
Signed-off-by: Hong Liu [EMAIL PROTECTED]
diff --git a/include/net/d80211.h b/include/net/d80211.h
index 812f2d1..2570072 100644
--- a/include/net/d80211.h
+++ b/include/net/d80211.h
@@ -159,6 +159,7 @@ #define IEEE80211_TXCTL_CLEAR_DST_MASK (
#define IEEE80211_TXCTL_REQUEUE(17)
#define IEEE80211_TXCTL_FIRST_FRAGMENT (18) /* this is a first fragment of
* the frame */
+#define IEEE80211_TXCTL_TKIP_NEW_PHASE1_KEY (19)
u16 flags; /* tx control flags defined
* above */
u16 rts_cts_duration; /* duration field for RTS/CTS frame */
@@ -169,6 +170,8 @@ #define IEEE80211_TXCTL_FIRST_FRAGMENT (
* hw-set_key() */
u8 icv_len; /* length of the ICV/MIC field in octets */
u8 iv_len; /* length of the IV field in octets */
+ u8 tkip_keylen;
+ u8 tkip_key[16];/* generated RC4/phase1 key for hw TKIP */
u8 queue; /* hardware queue to use for this frame;
* 0 = highest, hw-queues-1 = lowest */
u8 sw_retry_attempt;/* number of times hw has tried to
@@ -487,6 +490,15 @@ #define IEEE80211_HW_MONITOR_DURING_OPER
* i.e. more than one skb per frame */
#define IEEE80211_HW_FRAGLIST (111)
+ /* calculate Michael MIC for an MSDU when doing hwcrypto */
+#define IEEE80211_HW_TKIP_INCLUDE_MMIC (112)
+ /* Do TKIP phase1 key mixing in stack to support cards only do
+* phase2 key mixing when doing hwcrypto */
+#define IEEE80211_HW_TKIP_REQ_PHASE1_KEY (113)
+ /* Do TKIP phase1 and phase2 key mixing in stack and send the generated
+* per-packet RC4 key with each TX frame when doing hwcrypto */
+#define IEEE80211_HW_TKIP_REQ_PHASE2_KEY (114)
+
u32 flags; /* hardware flags defined above */
/* This is the time in us to change channels
diff --git a/net/d80211/tkip.c b/net/d80211/tkip.c
index 7e3665a..fd02449 100644
--- a/net/d80211/tkip.c
+++ b/net/d80211/tkip.c
@@ -190,17 +190,16 @@ u8 * ieee80211_tkip_add_iv(u8 *pos, stru
return pos;
}
-
-/* Encrypt packet payload with TKIP using @key. @pos is a pointer to the
- * beginning of the buffer containing payload. This payload must include
- * headroom of eight octets for IV and Ext. IV and taildroom of four octets
- * for ICV. @payload_len is the length of payload (_not_ including extra
- * headroom and tailroom). @ta is the transmitter addresses. */
-void ieee80211_tkip_encrypt_data(struct crypto_tfm *tfm, struct ieee80211_key
*key,
-u8 *pos, size_t payload_len, u8 *ta)
+void ieee80211_tkip_gen_phase1key(struct ieee80211_key *key, u8 *ta,
+ u16 *phase1key)
{
- u8 rc4key[16];
+ tkip_mixing_phase1(ta, key-key[ALG_TKIP_TEMP_ENCR_KEY],
+ key-u.tkip.iv32, phase1key);
+}
+void ieee80211_tkip_gen_rc4key(struct ieee80211_key *key, u8 *ta,
+ u8 *rc4key)
+{
/* Calculate per-packet key */
if (key-u.tkip.iv16 == 0 || !key-u.tkip.tx_initialized) {
/* IV16 wrapped around - perform TKIP phase 1 */
@@ -211,7 +210,19 @@ void ieee80211_tkip_encrypt_data(struct
tkip_mixing_phase2(key-u.tkip.p1k, key-key[ALG_TKIP_TEMP_ENCR_KEY],
Re: [PATCH] fix integer overflow in H-TCP congestion control
When using H-TCP with a single flow on a 500Mbit connection (or less
actually), alpha can exceed 65000, so alpha needs to be a u32.
Signed-off-by: Gavin McCullagh [EMAIL PROTECTED]
Signed-off-by: Doug Leith [EMAIL PROTECTED]
diff --git a/net/ipv4/tcp_htcp.c b/net/ipv4/tcp_htcp.c
index 6edfe5e..8072b6d 100644
--- a/net/ipv4/tcp_htcp.c
+++ b/net/ipv4/tcp_htcp.c
@@ -23,7 +23,7 @@ module_param(use_bandwidth_switch, int,
MODULE_PARM_DESC(use_bandwidth_switch, turn on/off bandwidth switcher);
struct htcp {
- u16 alpha; /* Fixed point arith, 7 */
+ u32 alpha; /* Fixed point arith, 7 */
u8 beta; /* Fixed point arith, 7 */
u8 modeswitch; /* Delay modeswitch until we had at least one
congestion event */
u32 last_cong; /* Time since last congestion event end */
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/2]d80211: hardware TKIP support for ipw3945
On Wed, 2006-10-25 at 16:28 +0800, Hong Liu wrote:
I'd prefer to let the stack tell the driver when there is new phase1 key
generated.
Fine too, I guess.
+ u8 tkip_keylen;
What do you need that for? The driver should know whether it requested a
phase 1 or phase 2 key.
+ u8 tkip_key[16];/* generated RC4/phase1 key for hw TKIP */
Do we really have to stick this into this structure? But I'll let Jiri
figure out how to remove the structure bloat :)
+ /* calculate Michael MIC for an MSDU when doing hwcrypto */
+#define IEEE80211_HW_TKIP_INCLUDE_MMIC (112)
+ /* Do TKIP phase1 key mixing in stack to support cards only do
+ * phase2 key mixing when doing hwcrypto */
+#define IEEE80211_HW_TKIP_REQ_PHASE1_KEY (113)
+ /* Do TKIP phase1 and phase2 key mixing in stack and send the generated
+ * per-packet RC4 key with each TX frame when doing hwcrypto */
+#define IEEE80211_HW_TKIP_REQ_PHASE2_KEY (114)
Maybe a comment indicating that you must not set both of these flags
would be good. Or (see below)
Should there be some flag indicating if the hw/firmware checked the MIC
on reception? The current code has bad assumptions there:
(from the pre-flags version)
/* Some devices handle Michael MIC internally and do not include MIC in
* the received packets passed up. device_strips_mic must be set
* for such devices. The 'encryption' frame control bit is expected to
* be still set in the IEEE 802.11 header with this option unlike with
* the device_hides_wep configuration option.
*/
unsigned int device_strips_mic:1;
What if the devices leaves the MIC there but indicates if it was checked?
+ if (flags IEEE80211_HW_TKIP_REQ_PHASE1_KEY) {
...
+ } else if (flags IEEE80211_HW_TKIP_REQ_PHASE2_KEY) {
...
if you change the order of these tests then setting both flags will be
fine.
johannes
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] s2io: add PCI error recovery support
Hi,
s2io_card_down() will do few BAR0 read/write. As per
pci-error-recovery.txt Documentation we are not supposed to do any new
IO in error_detected().
Can you try using
atomic_set(sp-card_state, CARD_DOWN);
instead of s2io_card_down().
Also we have to add following if statement in beginning of s2io_isr().
if (atomic_read(nic-card_state) == CARD_DOWN)
return IRQ_NOTHANDLED.
If it is ok to do BAR0 read/write in error_detected() then patch is OK.
Ananda
-Original Message-
From: Linas Vepstas [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 24, 2006 2:55 PM
To: Raghavendra Koushik; Ananda Raju; Wen Xiong
Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED];
netdev@vger.kernel.org; Jeff Garzik; Andrew Morton
Subject: [PATCH] s2io: add PCI error recovery support
Koushik, Raju,
Please review, comment, and if you find this acceptable,
please forward upstream.
--linas
This patch adds PCI error recovery support to the
s2io 10-Gigabit ethernet device driver.
Tested, seems to work well.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: Raghavendra Koushik [EMAIL PROTECTED]
Cc: Ananda Raju [EMAIL PROTECTED]
Cc: Wen Xiong [EMAIL PROTECTED]
drivers/net/s2io.c | 77
+
drivers/net/s2io.h |5 +++
2 files changed, 82 insertions(+)
Index: linux-2.6.19-rc1-git11/drivers/net/s2io.c
===
--- linux-2.6.19-rc1-git11.orig/drivers/net/s2io.c 2006-10-20
12:24:17.0 -0500
+++ linux-2.6.19-rc1-git11/drivers/net/s2io.c 2006-10-24
16:19:49.0 -0500
@@ -434,11 +434,18 @@ static struct pci_device_id s2io_tbl[] _
MODULE_DEVICE_TABLE(pci, s2io_tbl);
+static struct pci_error_handlers s2io_err_handler = {
+ .error_detected = s2io_io_error_detected,
+ .slot_reset = s2io_io_slot_reset,
+ .resume = s2io_io_resume,
+};
+
static struct pci_driver s2io_driver = {
.name = S2IO,
.id_table = s2io_tbl,
.probe = s2io_init_nic,
.remove = __devexit_p(s2io_rem_nic),
+ .err_handler = s2io_err_handler,
};
/* A simplifier macro used both by init and free shared_mem Fns(). */
@@ -7564,3 +7571,73 @@ static void lro_append_pkt(nic_t *sp, lr
sp-mac_control.stats_info-sw_stat.clubbed_frms_cnt++;
return;
}
+
+/**
+ * s2io_io_error_detected - called when PCI error is detected
+ * @pdev: Pointer to PCI device
+ * @state: The current pci conneection state
+ *
+ * This function is called after a PCI bus error affecting
+ * this device has been detected.
+ */
+static pci_ers_result_t s2io_io_error_detected(struct pci_dev *pdev,
pci_channel_state_t state)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ nic_t *sp = netdev-priv;
+
+ netif_device_detach(netdev);
+
+ if (netif_running(netdev)) {
+ /* Reset card */
+ s2io_card_down(sp);
+ sp-device_close_flag = TRUE; /* Device is shut down.
*/
+ }
+ pci_disable_device(pdev);
+
+ return PCI_ERS_RESULT_NEED_RESET;
+}
+
+/**
+ * s2io_io_slot_reset - called after the pci bus has been reset.
+ * @pdev: Pointer to PCI device
+ *
+ * Restart the card from scratch, as if from a cold-boot.
+ */
+static pci_ers_result_t s2io_io_slot_reset(struct pci_dev *pdev)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ nic_t *sp = netdev-priv;
+
+ if (pci_enable_device(pdev)) {
+ printk(KERN_ERR s2io: Cannot re-enable PCI device after
reset.\n);
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+
+ pci_set_master(pdev);
+ s2io_reset(sp);
+
+ return PCI_ERS_RESULT_RECOVERED;
+}
+
+/**
+ * s2io_io_resume - called when traffic can start flowing again.
+ * @pdev: Pointer to PCI device
+ *
+ * This callback is called when the error recovery driver tells us that
+ * its OK to resume normal operation.
+ */
+static void s2io_io_resume(struct pci_dev *pdev)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ nic_t *sp = netdev-priv;
+
+ if (netif_running(netdev)) {
+ if (s2io_card_up(sp)) {
+ printk(KERN_ERR s2io: can't bring device back
up after reset\n);
+ return;
+ }
+ }
+
+ netif_device_attach(netdev);
+ netif_wake_queue(netdev);
+}
Index: linux-2.6.19-rc1-git11/drivers/net/s2io.h
===
--- linux-2.6.19-rc1-git11.orig/drivers/net/s2io.h 2006-10-20
12:24:17.0 -0500
+++ linux-2.6.19-rc1-git11/drivers/net/s2io.h 2006-10-20
12:41:39.0 -0500
@@ -1013,6 +1013,11 @@ static void queue_rx_frame(struct sk_buf
static void update_L3L4_header(nic_t *sp, lro_t *lro);
static void lro_append_pkt(nic_t *sp, lro_t *lro, struct sk_buff *skb,
u32 tcp_len);
+static pci_ers_result_t s2io_io_error_detected(struct pci_dev *pdev,
+
pci_channel_state_t
about 802.11i IBSS support
Hi, I am reading the 802.11i IBSS spec and trying to find if it is OK to add patches to d80211 to support this feature. For 802.11i IBSS to work, each STA assumes two roles: supplicant + authenticator. Usually in BSS network, authenticator is in AP. The problem is the distribution of group keys. The group key is used for one-to-many communication. In BSS, the one is the AP, so the AP is responsible for the distribution of the group key. In IBSS, every STA has its own group key, used to broadcast data to other STAs. When a STA (say S1) joins in an IBSS network with N STAs, it must negotiate keys with all N STAs. The process for negotiation with one STA is as follows: 1. S1 init a 4-way handshake with one STA (say S2), to derive the pairwise key between them and then S1 sends its group key to S2, let S2 can decrypt s1's broadcast data. 2. S2 init the second 4-way handshake with S1, the main purpose for this 4-way handshake is for S2 to send its group key to S1, although this will also derive a second pairwise key. 3. Because in an IBSS there are two 4-Way Handshakes between any two STA Supplicants and Authenticators, the pairwise key used between any two STAs is from the 4-Way Handshake initiated by the STA Authenticator with the higher MAC address. So any STA in an IBSS network with N STAs must keep 2N-1 keys (N-1 for pairwise key and N for group key). We need the following parts to make 802.11i IBSS work: 1. for the d80211 part: I don't think there will be much efforts. We may add a group key to each sta_info for decrypting multicast data from that STA. And in RX path, we need to add code to select the correct group key for decryption. And also we need to store our own group key used to send multicast data to others. It should not be difficult because the infrastructures are all there in the dscape stack. 2. wpa_supplicant: this is the big part, we need to implement the authenticator in it. Not sure how much efforts needed? Thanks, Hong - 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: rmmod bcm43xx-d80211 while keys set etc
On Wednesday 25 October 2006 00:39, Johannes Berg wrote: resulted in this: [10261.556773] BUG: sleeping function called from invalid context at kernel/mutex.c:86 Yeah, there are a few bugs of this type left and I know most of them. ;) The stack should never call atomically into the driver. That must be made a hard general rule. [10261.556777] in_atomic():1, irqs_disabled():0 [10261.556780] Call Trace: [10261.556783] [C13CDC80] [C0008ED4] show_stack+0x3c/0x194 (unreliable) [10261.556799] [C13CDCB0] [C0025AE4] __might_sleep+0xd0/0xe4 [10261.556810] [C13CDCC0] [C02B90F8] mutex_lock+0x24/0x3c [10261.556819] [C13CDCE0] [F290647C] bcm43xx_net_set_key+0xd0/0x2d0 [bcm43xx_d80211] [10261.556854] [C13CDD10] [F248DEF4] sta_info_free+0x1b4/0x2c8 [80211] [10261.556906] [C13CDD50] [F248E078] sta_info_flush+0x70/0xa0 [80211] [10261.556918] [C13CDD70] [F2496728] ieee80211_if_reinit+0x10c/0x2cc [80211] [10261.556931] [C13CDDA0] [F2496908] __ieee80211_if_del+0x20/0x4c [80211] [10261.556943] [C13CDDC0] [F2485428] ieee80211_unregister_hw+0x78/0x248 [80211] [10261.556955] [C13CDDF0] [F29079F0] bcm43xx_remove_one+0x38/0x7c [bcm43xx_d80211] [10261.556966] [C13CDE10] [C017958C] pci_device_remove+0x38/0x60 [10261.556976] [C13CDE20] [C01CC59C] __device_release_driver+0x74/0xac [10261.556985] [C13CDE40] [C01CCCBC] driver_detach+0x110/0x140 [10261.556991] [C13CDE60] [C01CC0B8] bus_remove_driver+0x8c/0xc8 [10261.556996] [C13CDE80] [C01CCD44] driver_unregister+0x18/0x34 [10261.557001] [C13CDEA0] [C0179608] pci_unregister_driver+0x1c/0x70 [10261.557006] [C13CDEC0] [F291C9E0] bcm43xx_exit+0x18/0x3a90 [bcm43xx_d80211] [10261.557015] [C13CDED0] [C004A31C] sys_delete_module+0x1ac/0x210 [10261.557026] [C13CDF40] [C0010D20] ret_from_syscall+0x0/0x38 [10261.557035] --- Exception: c01 at 0xff6c2b8 [10261.557061] LR = 0x1000100c [10261.557073] Badness in __mutex_lock_common at kernel/mutex.c:132 [10261.557076] Call Trace: [10261.557078] [C13CDB50] [C0008ED4] show_stack+0x3c/0x194 (unreliable) [10261.557084] [C13CDB80] [C000FCA4] program_check_exception+0x47c/0x598 [10261.557090] [C13CDBD0] [C001137C] ret_from_except_full+0x0/0x4c [10261.557094] --- Exception: 700 at __mutex_lock_slowpath+0x168/0x170 [10261.557100] LR = __mutex_lock_slowpath+0x160/0x170 [10261.557103] [C13CDC90] [0003] 0x3 (unreliable) [10261.557108] [C13CDCE0] [F290647C] bcm43xx_net_set_key+0xd0/0x2d0 [bcm43xx_d80211] [10261.557118] [C13CDD10] [F248DEF4] sta_info_free+0x1b4/0x2c8 [80211] [10261.557133] [C13CDD50] [F248E078] sta_info_flush+0x70/0xa0 [80211] [10261.557144] [C13CDD70] [F2496728] ieee80211_if_reinit+0x10c/0x2cc [80211] [10261.557156] [C13CDDA0] [F2496908] __ieee80211_if_del+0x20/0x4c [80211] [10261.557168] [C13CDDC0] [F2485428] ieee80211_unregister_hw+0x78/0x248 [80211] [10261.557180] [C13CDDF0] [F29079F0] bcm43xx_remove_one+0x38/0x7c [bcm43xx_d80211] [10261.557189] [C13CDE10] [C017958C] pci_device_remove+0x38/0x60 [10261.557195] [C13CDE20] [C01CC59C] __device_release_driver+0x74/0xac [10261.557200] [C13CDE40] [C01CCCBC] driver_detach+0x110/0x140 [10261.557205] [C13CDE60] [C01CC0B8] bus_remove_driver+0x8c/0xc8 [10261.557210] [C13CDE80] [C01CCD44] driver_unregister+0x18/0x34 [10261.557215] [C13CDEA0] [C0179608] pci_unregister_driver+0x1c/0x70 [10261.557220] [C13CDEC0] [F291C9E0] bcm43xx_exit+0x18/0x3a90 [bcm43xx_d80211] [10261.557229] [C13CDED0] [C004A31C] sys_delete_module+0x1ac/0x210 [10261.557235] [C13CDF40] [C0010D20] ret_from_syscall+0x0/0x38 [10261.557240] --- Exception: c01 at 0xff6c2b8 [10261.557245] LR = 0x1000100c [10261.557322] eth1: Removed STA 00:15:f2:3d:63:97 [10261.623773] bcm43xx_d80211: Virtual interface removed (type: 0x0002, ID: 24, MAC: 00:11:24:91:07:4d) -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [PATCH] bcm43xx: (hopefully) fix watchdog timeouts.
On Wednesday 25 October 2006 02:37, John W. Linville wrote: Michael, It looks like you have a patch that I don't have, one that moves the netif_tx_disable and spin_lock_irqsave outside of the if (badness BADNESS_LIMIT) conditional. Could you pass that one along as well, or correct this patch to match what is in Linus' tree? Well, I'm not sure who moved the tx_disable outside of the conditional. It is not needed. We only need to disable TX on the slowpath (the first branch of the if condition). It does not hurt to disable it always, though. But I will send a new patch against wireless-2.6, which only disables TX for the slowpath and fakes a TX there. But for Greg, the original patch is ok. How was the stable mailing list again? [EMAIL PROTECTED] seems to bounce. -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.19-rc3 1/2] ehea: kzalloc GFP_ATOMIC fix
This patch fixes kzalloc parameters (GFP_ATOMIC instead of GFP_KERNEL)
Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED]
---
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index eb7d44d..4538c99 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -586,8 +586,8 @@ int ehea_sense_port_attr(struct ehea_por
u64 hret;
struct hcp_ehea_port_cb0 *cb0;
- cb0 = kzalloc(H_CB_ALIGNMENT, GFP_KERNEL);
- if (!cb0) {
+ cb0 = kzalloc(H_CB_ALIGNMENT, GFP_ATOMIC); /* May be called via */
+ if (!cb0) { /* ehea_neq_tasklet() */
ehea_error(no mem for cb0);
ret = -ENOMEM;
goto out;
@@ -765,8 +765,7 @@ static void ehea_parse_eqe(struct ehea_a
if (EHEA_BMASK_GET(NEQE_PORT_UP, eqe)) {
if (!netif_carrier_ok(port-netdev)) {
- ret = ehea_sense_port_attr(
- port);
+ ret = ehea_sense_port_attr(port);
if (ret) {
ehea_error(failed resensing port
attributes);
@@ -1502,7 +1501,7 @@ static void ehea_promiscuous(struct net_
if ((enable port-promisc) || (!enable !port-promisc))
return;
- cb7 = kzalloc(H_CB_ALIGNMENT, GFP_KERNEL);
+ cb7 = kzalloc(H_CB_ALIGNMENT, GFP_ATOMIC);
if (!cb7) {
ehea_error(no mem for cb7);
goto out;
@@ -1606,7 +1605,7 @@ static void ehea_add_multicast_entry(str
struct ehea_mc_list *ehea_mcl_entry;
u64 hret;
- ehea_mcl_entry = kzalloc(sizeof(*ehea_mcl_entry), GFP_KERNEL);
+ ehea_mcl_entry = kzalloc(sizeof(*ehea_mcl_entry), GFP_ATOMIC);
if (!ehea_mcl_entry) {
ehea_error(no mem for mcl_entry);
return;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.19-rc3 2/2] ehea: 64K page support fix
This patch fixes the 64K page support
Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED]
---
drivers/net/ehea/ehea.h |2 +-
drivers/net/ehea/ehea_phyp.h | 14 +-
drivers/net/ehea/ehea_qmr.c | 13 +++--
3 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index b40724f..cd412b5 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -39,7 +39,7 @@ #include asm/abs_addr.h
#include asm/io.h
#define DRV_NAME ehea
-#define DRV_VERSIONEHEA_0034
+#define DRV_VERSIONEHEA_0040
#define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
| NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
diff --git a/drivers/net/ehea/ehea_phyp.h b/drivers/net/ehea/ehea_phyp.h
index fa51e3b..59ab646 100644
--- a/drivers/net/ehea/ehea_phyp.h
+++ b/drivers/net/ehea/ehea_phyp.h
@@ -81,15 +81,27 @@ #define NELR_PORTSTATE_CHG EHEA_BMASK_IB
static inline void hcp_epas_ctor(struct h_epas *epas, u64 paddr_kernel,
u64 paddr_user)
{
+#ifdef CONFIG_PPC_64K_PAGES
+ /* To support 64k pages we must round to 64k page boundary */
+ epas-kernel.addr =
+ ioremap((paddr_kernel 0x), PAGE_SIZE) +
+ (paddr_kernel 0x);
+#else
epas-kernel.addr = ioremap(paddr_kernel, PAGE_SIZE);
+#endif
epas-user.addr = paddr_user;
}
static inline void hcp_epas_dtor(struct h_epas *epas)
{
+#ifdef CONFIG_PPC_64K_PAGES
+ if (epas-kernel.addr)
+ iounmap((void __iomem*)((u64)epas-kernel.addr
+ 0x));
+#else
if (epas-kernel.addr)
iounmap(epas-kernel.addr);
-
+#endif
epas-user.addr = 0;
epas-kernel.addr = 0;
}
diff --git a/drivers/net/ehea/ehea_qmr.c b/drivers/net/ehea/ehea_qmr.c
index 3e18623..3daedfa 100644
--- a/drivers/net/ehea/ehea_qmr.c
+++ b/drivers/net/ehea/ehea_qmr.c
@@ -512,7 +512,7 @@ int ehea_reg_mr_adapter(struct ehea_adap
start = KERNELBASE;
end = (u64)high_memory;
- nr_pages = (end - start) / PAGE_SIZE;
+ nr_pages = (end - start) / EHEA_PAGESIZE;
pt = kzalloc(PAGE_SIZE, GFP_KERNEL);
if (!pt) {
@@ -538,9 +538,9 @@ int ehea_reg_mr_adapter(struct ehea_adap
if (nr_pages 1) {
u64 num_pages = min(nr_pages, (u64)512);
for (i = 0; i num_pages; i++)
- pt[i] = virt_to_abs((void*)(((u64)start)
-+ ((k++) *
- PAGE_SIZE)));
+ pt[i] = virt_to_abs((void*)(((u64)start) +
+ ((k++) *
+EHEA_PAGESIZE)));
hret = ehea_h_register_rpage_mr(adapter-handle,
adapter-mr.handle, 0,
@@ -548,8 +548,9 @@ int ehea_reg_mr_adapter(struct ehea_adap
num_pages);
nr_pages -= num_pages;
} else {
- u64 abs_adr = virt_to_abs((void*)(((u64)start)
- + (k * PAGE_SIZE)));
+ u64 abs_adr = virt_to_abs((void*)(((u64)start) +
+ (k * EHEA_PAGESIZE)));
+
hret = ehea_h_register_rpage_mr(adapter-handle,
adapter-mr.handle, 0,
0, abs_adr,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: How to grab a block of binary data w/out using ioctls?
* Ben Greear | 2006-10-23 17:44:24 [-0700]: Since IOCTLs are out of favor these days, what would be a preferred way to get a block of binary data out of the kernel? I suggest netlink socket for that purpose! Netlink scales also well if the amount of data surprisedly rise. Thanks, Ben HGN - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tg3 driver fails with on-board BCM95789 NICS (GigaByte GA-7VCSV)
On 10/25/06, Michael Chan [EMAIL PROTECTED] wrote: ... Can you cat /proc/interrupts a few times to see if the interrupt counts on eth1 and eth2 are increasing? # grep eth /proc/interrupts 9: 0 0 0 0IO-APIC-edge eth2 16: 177724 0 371238 19350 IO-APIC-level libata, eth0, eth1 # ifconfig eth1;ifconfig eth2 eth1 Link encap:Ethernet HWaddr 00:16:E6:80:B1:3E inet addr:128.1.9.0 Bcast:128.1.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:15276 errors:0 dropped:0 overruns:0 frame:0 TX packets:30 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1389350 (1.3 Mb) TX bytes:1920 (1.8 Kb) Interrupt:16 eth2 Link encap:Ethernet HWaddr 00:16:E6:80:B1:3F UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:9 You can also run ethtool -t [eth1 | eth2] to run a basic selftest on the 2 devices. Be sure to ifconfig up first before the selftest. # ethtool -t eth1 The test result is PASS The test extra info: nvram test (online) 0 link test (online) 0 register test (offline) 0 memory test(offline) 0 loopback test (offline) 0 interrupt test (offline) 0 # ethtool -t eth2 The test result is FAIL The test extra info: nvram test (online) 0 link test (online) 1 register test (offline) 0 memory test(offline) 0 loopback test (offline) 0 interrupt test (offline) 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: about 802.11i IBSS support
On Wednesday 25 October 2006 10:54, Hong Liu wrote: 2. wpa_supplicant: this is the big part, we need to implement the authenticator in it. Not sure how much efforts needed? Well, I think that should go together with a merge of wpa_supplicant with hostapd (which I think is desired anyway). -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/1] myri10ge: use physical pages for skb allocation
The following patch reworks the myri10ge driver to use physical pages for skb allocation. A similar patch has been submitted about a month ago within our LRO patches. The LRO code won't be sent here since we are waiting for the core stack to implement a generic LRO. Please consider this single patch for 2.6.20. As explained previously, the complete driver code in our CVS also supports high-order allocations instead of single physical pages since it significantly increase the performance. But, since high-order allocations are generally considered a bad idea, we do not include the relevant code in the following patch for inclusion in Linux. Here, we simply pass order=0 to all page allocation routines. Thanks, Brice - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] myri10ge: use physical pages for skb allocation
Physical pages are used instead of 16kB contiguous buffers for the
skb frags. And we also put as much fragments as possible in any page
so that we do not have to allocate a page for every fragments.
Signed-off-by: Brice Goglin [EMAIL PROTECTED]
Signed-off-by: Andrew J. Gallatin [EMAIL PROTECTED]
---
drivers/net/myri10ge/myri10ge.c | 499
1 file changed, 254 insertions(+), 245 deletions(-)
Index: linux-rc/drivers/net/myri10ge/myri10ge.c
===
--- linux-rc.orig/drivers/net/myri10ge/myri10ge.c 2006-10-25
14:14:59.0 +0200
+++ linux-rc/drivers/net/myri10ge/myri10ge.c2006-10-25 14:15:18.0
+0200
@@ -61,6 +61,8 @@
#include linux/moduleparam.h
#include linux/io.h
#include net/checksum.h
+#include net/ip.h
+#include net/tcp.h
#include asm/byteorder.h
#include asm/io.h
#include asm/processor.h
@@ -71,7 +73,7 @@
#include myri10ge_mcp.h
#include myri10ge_mcp_gen_header.h
-#define MYRI10GE_VERSION_STR 1.0.0
+#define MYRI10GE_VERSION_STR 1.1.0
MODULE_DESCRIPTION(Myricom 10G driver (10GbE));
MODULE_AUTHOR(Maintainer: [EMAIL PROTECTED]);
@@ -91,9 +93,13 @@
#define MYRI10GE_NO_CONFIRM_DATA 0x
#define MYRI10GE_NO_RESPONSE_RESULT 0x
+#define MYRI10GE_ALLOC_ORDER 0
+#define MYRI10GE_ALLOC_SIZE ((1 MYRI10GE_ALLOC_ORDER) * PAGE_SIZE)
+#define MYRI10GE_MAX_FRAGS_PER_FRAME
(MYRI10GE_MAX_ETHER_MTU/MYRI10GE_ALLOC_SIZE + 1)
struct myri10ge_rx_buffer_state {
- struct sk_buff *skb;
+ struct page *page;
+ int page_offset;
DECLARE_PCI_UNMAP_ADDR(bus)
DECLARE_PCI_UNMAP_LEN(len)
};
@@ -116,9 +122,14 @@
u8 __iomem *wc_fifo;/* w/c rx dma addr fifo address */
struct mcp_kreq_ether_recv *shadow; /* host shadow of recv ring */
struct myri10ge_rx_buffer_state *info;
+ struct page *page;
+ dma_addr_t bus;
+ int page_offset;
int cnt;
+ int fill_cnt;
int alloc_fail;
int mask; /* number of rx slots -1 */
+ int watchdog_needed;
};
struct myri10ge_tx_buf {
@@ -150,6 +161,7 @@
struct myri10ge_rx_buf rx_big;
struct myri10ge_rx_done rx_done;
int small_bytes;
+ int big_bytes;
struct net_device *dev;
struct net_device_stats stats;
u8 __iomem *sram;
@@ -238,11 +250,6 @@
MODULE_PARM_DESC(myri10ge_force_firmware,
Force firmware to assume aligned completions\n);
-static int myri10ge_skb_cross_4k = 0;
-module_param(myri10ge_skb_cross_4k, int, S_IRUGO | S_IWUSR);
-MODULE_PARM_DESC(myri10ge_skb_cross_4k,
-Can a small skb cross a 4KB boundary?\n);
-
static int myri10ge_initial_mtu = MYRI10GE_MAX_ETHER_MTU - ETH_HLEN;
module_param(myri10ge_initial_mtu, int, S_IRUGO);
MODULE_PARM_DESC(myri10ge_initial_mtu, Initial MTU\n);
@@ -266,6 +273,10 @@
module_param(myri10ge_debug, int, 0);
MODULE_PARM_DESC(myri10ge_debug, Debug level (0=none,...,16=all));
+static int myri10ge_fill_thresh = 256;
+module_param(myri10ge_fill_thresh, int, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(myri10ge_fill_thresh, Number of empty rx slots allowed\n);
+
#define MYRI10GE_FW_OFFSET 1024*1024
#define MYRI10GE_HIGHPART_TO_U32(X) \
(sizeof (X) == 8) ? ((u32)((u64)(X) 32)) : (0)
@@ -797,194 +808,179 @@
mb();
}
-/*
- * Set of routines to get a new receive buffer. Any buffer which
- * crosses a 4KB boundary must start on a 4KB boundary due to PCIe
- * wdma restrictions. We also try to align any smaller allocation to
- * at least a 16 byte boundary for efficiency. We assume the linux
- * memory allocator works by powers of 2, and will not return memory
- * smaller than 2KB which crosses a 4KB boundary. If it does, we fall
- * back to allocating 2x as much space as required.
- *
- * We intend to replace large (4KB) skb allocations by using
- * pages directly and building a fraglist in the near future.
- */
-
-static inline struct sk_buff *myri10ge_alloc_big(struct net_device *dev,
-int bytes)
-{
- struct sk_buff *skb;
- unsigned long data, roundup;
-
- skb = netdev_alloc_skb(dev, bytes + 4096 + MXGEFW_PAD);
- if (skb == NULL)
- return NULL;
-
- /* Correct skb-truesize so that socket buffer
-* accounting is not confused the rounding we must
-* do to satisfy alignment constraints.
-*/
- skb-truesize -= 4096;
-
- data = (unsigned long)(skb-data);
- roundup = (-data) (4095);
- skb_reserve(skb, roundup);
- return skb;
-}
-
-/* Allocate 2x as much space as required and use whichever portion
- * does not cross a 4KB boundary */
-static inline struct sk_buff *myri10ge_alloc_small_safe(struct net_device *dev,
- unsigned int bytes)
+static inline void myri10ge_vlan_ip_csum(struct sk_buff *skb, u16
Re: tg3 driver fails with on-board BCM95789 NICS (GigaByte GA-7VCSV)
On 10/25/06, David Miller [EMAIL PROTECTED] wrote: It's an interrupt routing problem for sure, Adrian Bunk posted a potential fix to this poster an hour or so ago. I'm running with arch=i386 and the only related postings I see are for x86_64 :-(. - 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: watchdog timeout panic in e1000 driver
Hi, This problem originally occurred in a very large cluster system using snmp for server management. About two servers panicked each day. The program I sent is to reproduce this problem in a very short time. It does occur under normal load when there is a lot of servers. hmm, not good - does your snmp daemon use ethtool excessively? That would certainly be painful to the driver (any driver!). I only looked at the panic message after this problem occurred. I could tell that the snmp daemon caused the panic while trying to process the ethtool's ioctl, but I don't know how often this was called. However, it shouldn't be excessively called because it occurred on a production system while it was idle. Anyway as I said in the same e-mail, we're working on reducing the lock timeout to a reasonable time. This will unfortunately take some time, as we need to change some major components in the driver to make sure this doesn't happen. How about the following approach? If acquiring semaphore fails inside the interrupt handler, acquiring semaphore is abandoned immediately without waiting for timeout. However, I don't know whether this method affects other processes. -- Kenzo Iwami ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 1/3] adds iso3166-1 support
On 10/24/06, Johannes Berg [EMAIL PROTECTED] wrote: On Tue, 2006-10-24 at 11:59 -0400, Luis R. Rodriguez wrote: also if we index based on alpha3 we get O(1) access to the elements. Will make these changes. I wouldn't do that, it's bound to make the array size explode because there'll be one country starting with A and one starting with Z. You are right. Probably better to do a binary search and make sure (by hand) it's sorted. Will work on it when I get time, thanks. Luis - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 1/3] adds iso3166-1 support
On 10/24/06, Anand Kumria [EMAIL PROTECTED] wrote: On Mon, 23 Oct 2006 18:45:23 -0400, Luis R. Rodriguez wrote: iso3166-1 ISO 3166-1, as part of the ISO 3166 standard, provides codes for the names of countries and dependent areas. It was first published in 1974 by the International Organization for Standardization (ISO) and defines three different codes for each area: [snip] + r |= iso3166_1_add(887, YE, YEM, + Yemen); + r |= iso3166_1_add(891, CS, SCG, + Serbia and Montenegro); + r |= iso3166_1_add(894, ZM, ZMB, + Zambia); According to the ISO, at: http://www.iso.org/iso/en/commcentre/pressreleases/2006/Ref1031.html and http://www.iso.org/iso/en/prods-services/iso3166ma/03updates-on-iso-3166/nlv12-div.html Serbia and Montenegro have been allocated new codes, RS and ME respectively. Will update accordingly, thanks. Is this ISO3166 stuff supposed to track the standard? Yes. If so, what happens when a country splits or two join together? We update it. Will that require lock-step updates to user-space, or will it be insulated by this changes? I didn't intend on having a userspace update this as I figured these updates are rare and could just go with a new kernel release, and as this would currently only be used for regulatory domain control it should't have a negative impact. If there are more modules which can make use of this then perhaps we can consider a more robust interface. Luis - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] s2io: add PCI error recovery support
On Wed, Oct 25, 2006 at 02:29:33AM -0400, Ananda Raju wrote: Hi, s2io_card_down() will do few BAR0 read/write. As per pci-error-recovery.txt Documentation we are not supposed to do any new IO in error_detected(). Hmm, actually, its harmless to do further i/o. The s2io driver barks (as it should) because the result of reads is always 0x. Can you try using atomic_set(sp-card_state, CARD_DOWN); instead of s2io_card_down(). I will try that. I was mostly concerned that s2io_card_down() also may do some other important things with regards to the driver state, things which might be needed to keep the down-up sequence symmetrical. I wasn't sure, so I took the conservative route. Also we have to add following if statement in beginning of s2io_isr(). if (atomic_read(nic-card_state) == CARD_DOWN) return IRQ_NOTHANDLED. Right! Will revise this patch shortly. If it is ok to do BAR0 read/write in error_detected() then patch is OK. Its OK on pSeries, and I beleive it will be OK on PCIE, but I do not quite know enough about actual PCIE chipsets. --linas - 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] [PATCH 2/3] adds ieee80211_regdomains support
On 10/24/06, Anand Kumria [EMAIL PROTECTED] wrote:
On Mon, 23 Oct 2006 18:47:25 -0400, Luis R. Rodriguez wrote:
ieee80211_regdomains
Breaks down regulatory domains into data structures which allow
drivers to share channel and power contraints based on stack
regulatory domain. This driver adds in-kernel support for common
regulatory domains (such as FCC and ETSI), makes updating the
[snip]
+/* Stack regulatory domain values. Atheros seems to have started this
+ * convention and most hardware vendors followed their example.
+ * Although these are *very* common we allow for a hw-specific
+ * map between stack and device regdomain values. */
+enum stack_regdomain {
+ REGDOMAIN_WORLD = 0x00, /* World compliance, minimum set */
+ REGDOMAIN_FCC = 0x10, /* USA */
+ REGDOMAIN_IC= 0x20, /* Canada */
+ REGDOMAIN_ETSI = 0x30, /* Europe */
+ REGDOMAIN_SPAIN = 0x31, /* Spain */
+ REGDOMAIN_FRANCE= 0x32, /* France */
+ REGDOMAIN_MKK = 0x40, /* Japan */
+};
+
Why not pick either the country name or the organisation within the country
that determines the frequency guidelines?
Ultimately I think this is the way this should work and this is why I
provide a alpha3 country code -- stack regulatory domain map.
Userpace should just let the user pick the country at say,
distribution install time, and the map then used to determine the
regulatory domain. Regulatory domains are what dictate the subband
restrictions and as such these are ultimately what we need in the
stack to decide what goes and what doesn't.
Luis
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: about 802.11i IBSS support
On Wed, Oct 25, 2006 at 04:54:41PM +0800, Hong Liu wrote: I am reading the 802.11i IBSS spec and trying to find if it is OK to add patches to d80211 to support this feature. Large parts of this will be outside d80211, but yes, I think d80211 should be made ready to support this (mainly in the multiple group keys area). When a STA (say S1) joins in an IBSS network with N STAs, it must negotiate keys with all N STAs. I don't think it is required to negotiate keys with all STAs of the network unless it actually needs to communicate with them, i.e., there may be cases where it is not needed to send or receive data from some of the nodes. We need the following parts to make 802.11i IBSS work: 1. for the d80211 part: I don't think there will be much efforts. We may add a group key to each sta_info for decrypting multicast data from that STA. And in RX path, we need to add code to select the correct group key for decryption. And also we need to store our own group key used to send multicast data to others. This will also include looking into how different WLAN chipsets have implemented (or will implement) hardware acceleration for such a case. In addition, there will likely be need for some new kernel-to-userspace events to notify supplicant/authenticator that communication with a new target is needed. I don't think the standard has strict requirements on how this is done and there may be different preferences based on the application, so adding a generic mechanism for this would be nice. 2. wpa_supplicant: this is the big part, we need to implement the authenticator in it. Not sure how much efforts needed? This is on my to-do list for wpa_supplicant/hostapd 0.6 branch where it will be possible to link in part of wpa_supplicant and hostapd together into a single program. In other words, the authenticator code (both IEEE 802.1X/EAPOL and WPA/WPA2) will be available from hostapd. -- 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
Network virtualization/isolation
Hi Stephen, currently the work to make the container enablement into the kernel is doing good progress. The ipc, pid, utsname and filesystem system ressources are isolated/virtualized relying on the namespaces concept. But, there is missing the network virtualization/isolation. Two approaches are proposed: doing the isolation at the layer 2 and at the layer 3. The first one instanciate a network device by namespace and add a peer network device into the root namespace, all the routing ressources are relative to the namespace. This work is done by Andrey Savochkin from the openvz project. The second relies on the routes and associates the network namespace pointer with each route. When the traffic is incoming, the packet follows an input route and retrieve the associated network namespace. When the traffic is outgoing, the packet, identified from the network namespace is coming from, follows only the routes matching the same network namespace. This work is made by me. IMHO, we need the two approach, the layer-2 to be able to bring *very* strong isolation for system container with a performance cost and a layer-3 to be able to have good isolation for lightweight container or application container when performances are more important. Do you have some suggestions ? What is your point of view on that ? Thanks in advance. -- 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
linux-2.6.19-rc3-g7059abed build #99 failed
Hello, the build with the attached .config failed, make ends with: ... LD arch/i386/boot/compressed/vmlinux OBJCOPY arch/i386/boot/vmlinux.bin HOSTCC arch/i386/boot/tools/build BUILD arch/i386/boot/bzImage Root device is (3, 8) Boot sector 512 bytes. Setup is 4714 bytes. System is 1218 kB Kernel: arch/i386/boot/bzImage is ready (#1) Building modules, stage 2. MODPOST 161 modules WARNING: arp_broken_ops [drivers/net/wan/sealevel.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Here's the config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.19-rc3 # Wed Oct 25 11:24:28 2006 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # # CONFIG_EXPERIMENTAL is not set CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y # CONFIG_SYSVIPC is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set CONFIG_UTS_NS=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_IKCONFIG=y # CONFIG_IKCONFIG_PROC is not set CONFIG_RELAY=y CONFIG_INITRAMFS_SOURCE= CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODULE_UNLOAD is not set CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_KMOD is not set # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set CONFIG_MPENTIUMM=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y # CONFIG_HPET_TIMER is not set # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set # CONFIG_X86_UP_APIC is not set # CONFIG_X86_MCE is not set CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=m # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set CONFIG_DCDBAS=y CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set CONFIG_PAGE_OFFSET=0xC000 CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_RESOURCES_64BIT is not set # CONFIG_MATH_EMULATION is not set # CONFIG_MTRR is not set CONFIG_REGPARM=y CONFIG_SECCOMP=y CONFIG_HZ_100=y # CONFIG_HZ_250 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=100 CONFIG_KEXEC=y CONFIG_PHYSICAL_START=0x10 CONFIG_COMPAT_VDSO=y # # Power management options (ACPI, APM) # CONFIG_PM=y CONFIG_PM_LEGACY=y CONFIG_PM_DEBUG=y CONFIG_DISABLE_CONSOLE_SUSPEND=y # CONFIG_PM_SYSFS_DEPRECATED is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # # # APM (Advanced Power
Re: Network virtualization/isolation
On Wed, 25 Oct 2006 17:51:28 +0200 Daniel Lezcano [EMAIL PROTECTED] wrote: Hi Stephen, currently the work to make the container enablement into the kernel is doing good progress. The ipc, pid, utsname and filesystem system ressources are isolated/virtualized relying on the namespaces concept. But, there is missing the network virtualization/isolation. Two approaches are proposed: doing the isolation at the layer 2 and at the layer 3. The first one instanciate a network device by namespace and add a peer network device into the root namespace, all the routing ressources are relative to the namespace. This work is done by Andrey Savochkin from the openvz project. The second relies on the routes and associates the network namespace pointer with each route. When the traffic is incoming, the packet follows an input route and retrieve the associated network namespace. When the traffic is outgoing, the packet, identified from the network namespace is coming from, follows only the routes matching the same network namespace. This work is made by me. IMHO, we need the two approach, the layer-2 to be able to bring *very* strong isolation for system container with a performance cost and a layer-3 to be able to have good isolation for lightweight container or application container when performances are more important. Do you have some suggestions ? What is your point of view on that ? Thanks in advance. -- Daniel Any solution should allow both and it should build on the existing netfilter infrastructure. -- 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: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
On 10/25/06, Jiri Benc [EMAIL PROTECTED] wrote: On Tue, 24 Oct 2006 13:41:12 -0400, Luis R. Rodriguez wrote: Sure -- we can have on the ieee80211_conf struct an array of all regulatory domains stack values that the device supports (REGDOMAIN_FCC or 0x10 for FCC for example) if the developer agrees the device has been certified to match the regulatory domain restrictions as the stack defines it. I believe most modern devices adhere to the PtMP restrictions pretty loosely and the magic is left to the driver when the device is being certified so ultimately I see devices sharing regulatory domains restrictions rather than defining their own though. I'd consider defining your own device-specific regulatory domain would be more of an exception we'd have to deal with but that remains to be seen yet huh. It sounds overcomplicated to me. I'd rather like to see something like this: 1. As part of the initialization of the hardware, the driver detects that the device is certified for (say) channels 2 to 10 (that's not a real-life example, fortunately :-)). BTW we should also record the max Intentional Radiator (IR) power and define the default antenna gain then. That way the max IR to be used can be restricted by regdomain max EIRP - antenna gain. Currently d80211.h ieee80211_conf has a u8 power_level and u8 antenna_max. I assume antenna_max here is max antenna gain, but is power_level max IR or max computed EIRP? If its max IR then great. 2. The driver reports this somewhere (softmac drivers would report this to the stack). The the ieee80211_conf struct should work. 3. Based on outside conditions (userspace - or something - tells us about actual regdomain), the stack (or whatever) calls the driver and passes allowed channels etc. to it (if the driver wants that information). There is already previously reported driver's limitation taken in the account in that information. BTW this was what I intended for phase I for ieee80211_regdomain on d80211. Currently d80211 drivers define their channels as an array. After we cleared how we'd integrate it into the stack I then wanted to write a get_reg_channels(dev) and we'd use the device's mode and stack regdomain to give the driver back all valid channels for the stack's current regdomain. 4. If the outside conditions change (802.11d or user emigrates or something) that callback is called again with a new data. Through this approach the question then becomes do we inspect the device's saved limitations and compare to available regulatory domains and (a) based on that comparison select only a few regulatory domains that the device supports, or (b) do we do allow the device to jump to any regulatory domain and later do the proper validation? I think (a) is the way to go and is similar to what I suggested in the quoted text above but is more of a dynamic autoselection of supported regultory domains vs the driver-writer-lists-supported-regdomains approach. This is overcomplicated but AFAICT no other wireless stack has taken a good stab at assuring devices comply to regdomains centrally through a wireless stack. The problem is that dealing with all wireless devices and coming up with a way to assure all do comply to regulatory domains in a meaninful logical way without regard to where the MLME is implemented is slightly overcomplicated. I.e.: - I see no point in building a list of regdomains suported by the hardware. Point taken -- the regulatory domain should just mask the device's capabilities based on locale. - It's pretty common that the device has some limitation stated in the EPROM and the stack/something should deal with it in a way that is easy to use in a driver. ACK Luis - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to grab a block of binary data w/out using ioctls?
Jeff Garzik wrote: On Tue, Oct 24, 2006 at 09:35:49PM -0700, Randy Dunlap wrote: Please grep for sysfs_create_bin_file, you will find plenty of examples. Hm, I thought that sysfs binary files were supposed to be for transparent blobs of data, not for structured data. E.g., a firmware blob would be OK. Depends. Normally ASCII is greatly preferred, but passing in/out big data structures can be a huge pain, thunking to/from ASCII. This is my scenario exactly. It is also much easier to make sure the data is coherent if I can grab it all at once. In my case, I'm wanting to add this to the pktgen module, for reporting stats. But, it seems sysfs is designed mostly for drivers with some sort of 'object' behind it. Would I need to create some faked out dummy object in order to use sysfs with pktgen? I also notice there is already a /sys/modules/pktgen node in sysfs..is there any easy way to stick my binary file interface in that directory? Thanks, Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tg3 driver fails with on-board BCM95789 NICS (GigaByte GA-7VCSV)
On Wed, 2006-10-25 at 09:02 -0400, Richard Bollinger wrote: # ethtool -t eth2 The test result is FAIL The test extra info: nvram test (online) 0 link test (online) 1 register test (offline) 0 memory test(offline) 0 loopback test (offline) 0 interrupt test (offline) 1 This confirms that it's some kind of interrupt problem as David had suggested, at least on eth2. You can try booting with noapic to see if it works if you haven't got the patch from Adrian Bunk yet. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
e100: Wait for PHY reset to complete?
Shouldn't the e100 driver wait for PHY reset to complete before
proceeding in e100_set_settings()?
I'm asking because the interface (82551) sometimes ends up in loopback
when I try to set AUTONEG.
I'm thinking something like this patch.
Anders
--- linux-2.6.18.orig/drivers/net/e100.c2006-09-20 05:42:06.0
+0200
+++ linux-2.6.18/drivers/net/e100.c 2006-10-17 17:43:47.0 +0200
@@ -2201,8 +2201,16 @@ static int e100_set_settings(struct net_
{
struct nic *nic = netdev_priv(netdev);
int err;
+ int counter = 50;
mdio_write(netdev, nic-mii.phy_id, MII_BMCR, BMCR_RESET);
+
+ /* wait for possibly (ouch) 500ms */
+ while (mdio_read(netdev, nic-mii.phy_id, MII_BMCR) BMCR_RESET) {
+ msleep(10);
+ if (!--counter) break;
+ }
+
err = mii_ethtool_sset(nic-mii, cmd);
e100_exec_cb(nic, NULL, e100_configure);
-
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] [PATCH 0/3] Add Regulatory Domain support to d80211
On 10/24/06, Michael Wu [EMAIL PROTECTED] wrote: On Tuesday 24 October 2006 18:03, Luis R. Rodriguez wrote: 1. Anyone working on completing FullMAC support on d80211? That doesn't really make sense. Fullmac devices should just use WE or cfg80211 because they, for the most part, do what d80211 does in firmware. There are also strange hybrid devices like ipw2100/ipw2200, but IMHO, it's not worth trying to bolt d80211 onto those devices unless saner firmware becomes available. I guess my hope was that d80211 would just be more than a softmac implementation. When I hear wireless stack I don't think softmac implementation, I think a robust set of headers and device definitions which all wireless devices can share. Also I thought we'd ditch WE as it seems we keep fixing it with gum (as seen by Linville's latest ABI compatibility fix). If that wasn't the case then I'm suggesting it -- can we consider ditching WE? I appologize to get seriously off-topic here BTW but think I need to say this. I mean -- we can keep on advancing WE but I really don't want to deal with any more sub-ioctl hacks. I think its beeg good for us but I think we're hitting the limit of its capabilities. Madwifi is an example of a driver which has been breeded to live in the extremes of WE -- you can't pack any more brand new ioctls there. Sub-ioctls were just that -- a hack. Let's stop this and look for a better solution. How about jumping on Johannes Berg's nl80211/cfg80211 and providing a new user API through that? 2. Who's working on a userspace MLME replacement for d80211 and where are we with that? I think HostAP can handle authentication/association.. or was it wpa-supplicant? Maybe both.. As confirmed by Simon, wpa_supplicant. OK great. 3. Who's doing the endianness/smp testing of d80211 and how far are we with that? The endianness issues seemed fine the last time I checked, and people do seem to be testing BE enough that to uncover an endianness regression I introduced when converting WEP code to use crypto api. As for SMP/locking, I think Jiri Benc knows how to deal with this. Jiri --- how is that coming along? :) Lastly, as I have said in previous e-mails -- I agree with a userspace daemon but where is it and how long before its ready.. also it may be difficult to introduce as a requirement for distributions and for this reason I am suggesting going with in-kernel regulatory domain control and now perhaps in-kernel MLME for a first stable push of d80211, specially since only... 3 in-kernel drivers currently use d80211! 4 once p54 is merged, and more to come as I get to them. /me pokes Linville. and zd1211rw too, now that I'm done with sending RFC for regdomains work. If I don't have time I'll pass what I have to you. I think time working on the in-kernel MLME is well worth it since I would like softmac drivers to have feature parity with fullmac drivers. Anything beyond that can go to userspace as far as I'm concerned. (so transitioning to d80211 based drivers won't involve too much pain unless you really want to take advantage of new features) Not having in-kernel MLME does not necessarily mean having a disparity between SoftMAC and FullMAC. To me its more of a speed issue and a requirement of having a userspace daemons before using a SoftMAC wireless device. I can see distributions having issues with the requirement of a new userspace daemon in order to use wireless SoftMAC devices and would argue that if we can complete the in-kernel MLME that perhaps we should do this for the introduction of d80211 to stable and later on move it to userspace. I'd say lets just go for a userspace MLME as its already written but I seriously think we need to ditch replace WE first. Having some basic regulatory domain control in d80211 in the kernel should be okay for now just to make sure all drivers like the api presented. Working out the details of how to move the d80211 side stuff to userspace should be orthogonal to the driver interface and can be dealt with later, IMHO. That is only true if we stick with WE. Luis - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
d80211: remove unused variable in ieee80211_rx_irqsafe
tmp is unused.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/ieee80211.c
===
--- wireless-dev.orig/net/d80211/ieee80211.c
+++ wireless-dev/net/d80211/ieee80211.c
@@ -3843,7 +3843,7 @@ void ieee80211_rx_irqsafe(struct net_dev
struct ieee80211_rx_status *status)
{
struct ieee80211_local *local = dev-ieee80211_ptr;
- struct ieee80211_rx_status *saved, *tmp;
+ struct ieee80211_rx_status *saved;
skb-dev = dev;
saved = kmalloc(sizeof(struct ieee80211_rx_status), GFP_ATOMIC);
--
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.19-rc3 2/2] ehea: 64K page support fix
Hi, +#ifdef CONFIG_PPC_64K_PAGES + /* To support 64k pages we must round to 64k page boundary */ + epas-kernel.addr = + ioremap((paddr_kernel 0x), PAGE_SIZE) + + (paddr_kernel 0x); +#else epas-kernel.addr = ioremap(paddr_kernel, PAGE_SIZE); +#endif Cant you just use PAGE_MASK, ~PAGE_MASK and remove the ifdefs completely? Anton - 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
[take3 3/5] d80211: remove bitfields from ieee80211_key_conf
All three one-bit bitfields have been subsumed into the new 'flags'
structure member and the new IEEE80211_KEY_* definitions. The 8 bit
keyidx bitfield is converted to type s8.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
@@ -3583,8 +3583,8 @@ static int bcm43xx_net_set_key(struct ne
if (err)
goto out_unlock;
key-hw_key_idx = index;
- key-force_sw_encrypt = 0;
- if (key-default_tx_key)
+ key-flags = ~IEEE80211_KEY_FORCE_SW_ENCRYPT;
+ if (key-flags IEEE80211_KEY_DEFAULT_TX_KEY)
bcm-default_key_idx = index;
bcm-key[index].enabled = 1;
break;
Index: wireless-dev/include/net/d80211.h
===
--- wireless-dev.orig/include/net/d80211.h
+++ wireless-dev/include/net/d80211.h
@@ -366,13 +366,19 @@ struct ieee80211_key_conf {
ieee80211_key_alg alg;
int keylen;
- unsigned int force_sw_encrypt:1;/* to be cleared by low-level driver */
- int keyidx:8; /* WEP key index */
- unsigned int default_tx_key:1; /* This key is the new default TX key
-* (used only for broadcast keys). */
- unsigned int default_wep_only:1;/* static WEP is the only configured
security
-* policy; this allows some low-level
drivers
-* to determine when hwaccel can be
used */
+#define IEEE80211_KEY_FORCE_SW_ENCRYPT (10) /* to be cleared by low-level
+driver */
+#define IEEE80211_KEY_DEFAULT_TX_KEY (11) /* This key is the new default TX
+key (used only for broadcast
+keys). */
+#define IEEE80211_KEY_DEFAULT_WEP_ONLY (12) /* static WEP is the only
+configured security policy;
+this allows some low-level
+drivers to determine when
+hwaccel can be used */
+ u8 flags; /* key configuration flags defined above */
+
+ s8 keyidx; /* WEP key index */
u8 key[0];
};
Index: wireless-dev/net/d80211/ieee80211.c
===
--- wireless-dev.orig/net/d80211/ieee80211.c
+++ wireless-dev/net/d80211/ieee80211.c
@@ -64,10 +64,14 @@ ieee80211_key_data2conf(struct ieee80211
conf-hw_key_idx = data-hw_key_idx;
conf-alg = data-alg;
conf-keylen = data-keylen;
- conf-force_sw_encrypt = data-force_sw_encrypt;
+ conf-flags = 0;
+ if (data-force_sw_encrypt)
+ conf-flags |= IEEE80211_KEY_FORCE_SW_ENCRYPT;
conf-keyidx = data-keyidx;
- conf-default_tx_key = data-default_tx_key;
- conf-default_wep_only = local-default_wep_only;
+ if (data-default_tx_key)
+ conf-flags |= IEEE80211_KEY_DEFAULT_TX_KEY;
+ if (local-default_wep_only)
+ conf-flags |= IEEE80211_KEY_DEFAULT_WEP_ONLY;
memcpy(conf-key, data-key, data-keylen);
return conf;
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/d80211/ieee80211_ioctl.c
@@ -331,7 +331,7 @@ static int ieee80211_ioctl_add_sta(struc
memset(conf, 0, sizeof(conf));
conf.hw_key_idx = HW_KEY_IDX_INVALID;
conf.alg = ALG_NULL;
- conf.force_sw_encrypt = 1;
+ conf.flags |= IEEE80211_KEY_FORCE_SW_ENCRYPT;
if (local-hw-set_key(dev, SET_KEY, sta-addr, conf,
sta-aid)) {
sta-key_idx_compression = HW_KEY_IDX_INVALID;
@@ -501,7 +501,7 @@ int ieee80211_set_hw_encryption(struct n
key-hw_key_idx = HW_KEY_IDX_INVALID;
} else {
key-force_sw_encrypt =
- keyconf-force_sw_encrypt;
+ !!(keyconf-flags
IEEE80211_KEY_FORCE_SW_ENCRYPT);
key-hw_key_idx =
keyconf-hw_key_idx;
@@ -2294,7 +2294,8 @@ static void ieee80211_key_enable_hwaccel
keyconf = ieee80211_key_data2conf(local, key);
if (keyconf local-hw-set_key
local-hw-set_key(local-mdev,
[take3 0/5] d80211: remove bitfields from include/net/d80211.h
Continue d80211 bitfield removal. In general, compilers have difficulty generating efficient code for bitfields. This patchset removes all bitfields from include/net/d80211.h. I converted the 1 bit bitfields into a bit in a u32/u16 or u8 flags structure member. Larger bitfields I converted into their u8/u16/whatever equivalent. This should be a no-op from a functionality standpoint. All tests using gcc 4.1.2. The size of structures where bitfields were removed is identical patched and unpatched. All object text size is either slightly smaller after the patch, or unchanged (bss and data are all unchanged). With all d80211 drivers compiled in the patched vmlinux is 1232 bytes smaller. Changes from take2: Refresh to apply to current wireless-dev. Changes from take1: Update rt2500usb.c and rt73usb.c drivers based on the new structures. Changes from take0: Update the patches to apply on top of the following patches: d80211: remove unused Super AG definitions, purge comment (http://marc.theaimsgroup.com/?l=linux-netdevm=116102409931269w=2) d80211: remove initialization of unused xr structure members (http://marc.theaimsgroup.com/?l=linux-netdevm=116076811809305w=4) d80211: remove unused xr structure members, interface, etc. (http://marc.theaimsgroup.com/?l=linux-netdevm=115989929600617w=4) For key_conf_bitfields.patch change the new flags member to u8 from u32. For tx_control_bitfields.patch move the rts_cts_duration and retry_limit members in ieee80211_tx_control to allow for smaller structure size and change the flags member from u32 to u16. For tx_status_bitfields.patch, in drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c and drivers/net/wireless/d80211/bcm43xx/bcm43xx_pio.c note that ieee80211_tx_status is already zero'd, so the ack bit only needs to be set, not cleared. -- - 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
[take3 1/5] d80211: remove bitfields from ieee80211_tx_control
All one-bit bitfields have been subsumed into the new 'flags'
structure member and the new IEEE80211_TXCTL_* definitions. The
multiple bit members were converted to u8, s8 or u16 as appropriate.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/include/net/d80211.h
===
--- wireless-dev.orig/include/net/d80211.h
+++ wireless-dev/include/net/d80211.h
@@ -141,36 +141,38 @@ struct ieee80211_tx_control {
int rts_cts_rate; /* Transmit rate for RTS/CTS frame, given as the hw
* specific value for the rate (from
* struct ieee80211_rate) */
- /* 1 = only first attempt, 2 = one retry, .. */
- unsigned int retry_limit:8;
- /* duration field for RTS/CTS frame */
- unsigned int rts_cts_duration:16;
- unsigned int req_tx_status:1; /* request TX status callback for this
- * frame */
- unsigned int do_not_encrypt:1; /* send this frame without encryption;
- * e.g., for EAPOL frames */
- unsigned int use_rts_cts:1; /* Use RTS-CTS before sending frame. */
- unsigned int use_cts_protect:1; /* Use CTS protection for the frame
-* (e.g., for combined 802.11g /
-* 802.11b networks) */
-unsigned int no_ack:1; /* Tell the low level not to wait for an ack */
- unsigned int rate_ctrl_probe:1;
- unsigned int clear_dst_mask:1;
- unsigned int requeue:1;
- unsigned int first_fragment:1; /* This is a first fragment of the
-* frame */
-unsigned int power_level:8; /* per-packet transmit power level, in dBm
-*/
- unsigned int antenna_sel:4; /* 0 = default/diversity,
-* 1 = Ant0, 2 = Ant1 */
- int key_idx:8; /* -1 = do not encrypt, = 0 keyidx from hw-set_key()
- */
- int icv_len:8; /* Length of the ICV/MIC field in octets */
- int iv_len:8; /* Length of the IV field in octets */
- unsigned int queue:4; /* hardware queue to use for this frame;
- * 0 = highest, hw-queues-1 = lowest */
- unsigned int sw_retry_attempt:4; /* no. of times hw has tried to
- * transmit frame (not incl. hw retries) */
+
+#define IEEE80211_TXCTL_REQ_TX_STATUS (10)/* request TX status callback for
+ * this frame */
+#define IEEE80211_TXCTL_DO_NOT_ENCRYPT (11) /* send this frame without
+ * encryption; e.g., for EAPOL
+ * frames */
+#define IEEE80211_TXCTL_USE_RTS_CTS(12) /* use RTS-CTS before sending
+ * frame */
+#define IEEE80211_TXCTL_USE_CTS_PROTECT(13) /* use CTS protection
for the
+ * frame (e.g., for combined
+ * 802.11g / 802.11b networks) */
+#define IEEE80211_TXCTL_NO_ACK (14) /* tell the low level not to
+ * wait for an ack */
+#define IEEE80211_TXCTL_RATE_CTRL_PROBE(15)
+#define IEEE80211_TXCTL_CLEAR_DST_MASK (16)
+#define IEEE80211_TXCTL_REQUEUE(17)
+#define IEEE80211_TXCTL_FIRST_FRAGMENT (18) /* this is a first fragment of
+ * the frame */
+ u16 flags; /* tx control flags defined
+ * above */
+ u16 rts_cts_duration; /* duration field for RTS/CTS frame */
+ u8 retry_limit; /* 1 = only first attempt, 2 = one retry, .. */
+ u8 power_level; /* per-packet transmit power level, in dBm */
+ u8 antenna_sel; /* 0 = default/diversity, 1 = Ant0, 2 = Ant1 */
+ s8 key_idx; /* -1 = do not encrypt, = 0 keyidx from
+* hw-set_key() */
+ u8 icv_len; /* length of the ICV/MIC field in octets */
+ u8 iv_len; /* length of the IV field in octets */
+ u8 queue; /* hardware queue to use for this frame;
+* 0 = highest, hw-queues-1 = lowest */
+ u8 sw_retry_attempt;/* number of times hw has tried to
+* transmit frame (not incl. hw retries) */
int rateidx; /* internal 80211.o rateidx */
int alt_retry_rate; /* retry rate for the last retries, given as the
Index: wireless-dev/net/d80211/ieee80211.c
===
--- wireless-dev.orig/net/d80211/ieee80211.c
+++ wireless-dev/net/d80211/ieee80211.c
@@ -354,7 +354,7 @@
[take3 5/5] d80211: remove bitfields from ieee80211_conf
All four one-bit bitfields have been subsumed into the new 'flags'
structure member and the new IEEE80211_CONF_* definitions.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/include/net/d80211.h
===
--- wireless-dev.orig/include/net/d80211.h
+++ wireless-dev/include/net/d80211.h
@@ -240,12 +240,12 @@ struct ieee80211_conf {
int beacon_int;
- /* Bitfields, grouped together */
-
- unsigned int sw_encrypt:1;
- unsigned int sw_decrypt:1;
- unsigned int short_slot_time:1; /* use IEEE 802.11g Short Slot Time */
- unsigned int ssid_hidden:1; /* do not broadcast the ssid */
+#define IEEE80211_CONF_SW_ENCRYPT (10)
+#define IEEE80211_CONF_SW_DECRYPT (11)
+#define IEEE80211_CONF_SHORT_SLOT_TIME (12) /* use IEEE 802.11g Short Slot
+ * Time */
+#define IEEE80211_CONF_SSID_HIDDEN (13) /* do not broadcast the ssid */
+ u32 flags; /* configuration flags defined above */
u8 power_level;/* transmit power limit for
current
* regulatory domain; in dBm */
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
@@ -3480,9 +3480,9 @@ static int bcm43xx_net_config(struct net
bcm43xx_radio_selectchannel(bcm, conf-channel_val, 0);
/* Enable/Disable ShortSlot timing. */
- if (conf-short_slot_time != bcm-short_slot) {
+ if (!!(conf-flags IEEE80211_CONF_SHORT_SLOT_TIME) !=
bcm-short_slot) {
assert(phy-type == BCM43xx_PHYTYPE_G);
- if (conf-short_slot_time)
+ if (conf-flags IEEE80211_CONF_SHORT_SLOT_TIME)
bcm43xx_short_slot_timing_enable(bcm);
else
bcm43xx_short_slot_timing_disable(bcm);
@@ -3495,7 +3495,7 @@ static int bcm43xx_net_config(struct net
}
/* Hide/Show the SSID (AP mode only). */
- if (conf-ssid_hidden) {
+ if (conf-flags IEEE80211_CONF_SSID_HIDDEN) {
bcm43xx_write32(bcm-wlcore, BCM43xx_MMIO_STATUS_BITFIELD,
bcm43xx_read32(bcm-wlcore,
BCM43xx_MMIO_STATUS_BITFIELD)
| BCM43xx_SBF_NO_SSID_BCAST);
Index: wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
+++ wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
@@ -742,7 +742,8 @@ static void rt2400pci_config_rate(struct
rt2x00_register_read(rt2x00dev, TXCSR1, reg[0]);
value = SIFS + PLCP
- + (2 * (conf-short_slot_time ? SHORT_SLOT_TIME : SLOT_TIME))
+ + (2 * ((conf-flags IEEE80211_CONF_SHORT_SLOT_TIME) ?
+ SHORT_SLOT_TIME : SLOT_TIME))
+ preamble
+ get_duration(ACK_SIZE, 10);
rt2x00_set_field32(reg[0], TXCSR1_ACK_TIMEOUT, value);
@@ -2080,7 +2081,8 @@ static int rt2400pci_config(struct net_d
conf-channel_val, conf-channel, conf-freq);
rt2400pci_config_txpower(rt2x00dev, conf-power_level);
rt2400pci_config_antenna(rt2x00dev, conf-antenna_sel);
- rt2400pci_config_duration(rt2x00dev, conf-short_slot_time);
+ rt2400pci_config_duration(rt2x00dev,
+ conf-flags IEEE80211_CONF_SHORT_SLOT_TIME);
rt2400pci_config_phymode(rt2x00dev, conf-phymode);
/*
Index: wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
+++ wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
@@ -808,7 +808,8 @@ static void rt2500pci_config_rate(struct
rt2x00_register_read(rt2x00dev, TXCSR1, reg[0]);
value = SIFS + PLCP
- + (2 * (conf-short_slot_time ? SHORT_SLOT_TIME : SLOT_TIME))
+ + (2 * ((conf-flags IEEE80211_CONF_SHORT_SLOT_TIME) ?
+ SHORT_SLOT_TIME : SLOT_TIME))
+ preamble
+ get_duration(ACK_SIZE, 10);
rt2x00_set_field32(reg[0], TXCSR1_ACK_TIMEOUT, value);
@@ -2230,7 +2231,8 @@ static int rt2500pci_config(struct net_d
conf-power_level);
rt2500pci_config_txpower(rt2x00dev, conf-power_level);
rt2500pci_config_antenna(rt2x00dev, conf-antenna_sel);
- rt2500pci_config_duration(rt2x00dev, conf-short_slot_time);
+ rt2500pci_config_duration(rt2x00dev,
+ conf-flags
[take3 4/5] d80211: remove bitfields from ieee80211_hw
All twelve one-bit bitfields have been subsumed into the new 'flags'
structure member and the new IEEE80211_HW_* definitions.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/drivers/net/wireless/d80211/adm8211/adm8211.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/adm8211/adm8211.c
+++ wireless-dev/drivers/net/wireless/d80211/adm8211/adm8211.c
@@ -2012,17 +2012,9 @@ static int __devinit adm8211_probe(struc
hw-version = 2;
hw-name = adm8211;
- hw-host_gen_beacon = 0;
- hw-device_hides_wep = 0;
- hw-rx_includes_fcs = 0;// however, FCS is kept in promisc mode
- hw-host_broadcast_ps_buffering = 0;
- hw-wep_include_iv = 1;
- hw-data_nullfunc_ack = 0;
- hw-no_tkip_wmm_hwaccel = 1;
- hw-extra_hdr_room = 0;
- hw-device_strips_mic = 0;
- hw-monitor_during_oper = 0;
- hw-fraglist = 0;
+ hw-flags = IEEE80211_HW_WEP_INCLUDE_IV |
IEEE80211_HW_NO_TKIP_WMM_HWACCEL;
+ // however, IEEE80211_HW_RX_INCLUDES_FCS in promisc mode
+
hw-channel_change_time = 1000;
hw-num_modes = 1;
Index: wireless-dev/include/net/d80211.h
===
--- wireless-dev.orig/include/net/d80211.h
+++ wireless-dev/include/net/d80211.h
@@ -437,19 +437,19 @@ struct ieee80211_hw {
* configure the upper layer IEEE 802.11 module to generate beacons.
* The low-level driver can use ieee80211_beacon_get() to fetch the
* next beacon frame. */
- unsigned int host_gen_beacon:1;
+#define IEEE80211_HW_HOST_GEN_BEACON (10)
/* The device needs to be supplied with a beacon template only. */
- unsigned int host_gen_beacon_template:1;
+#define IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE (11)
/* Some devices handle decryption internally and do not
* indicate whether the frame was encrypted (unencrypted frames
* will be dropped by the hardware, unless specifically allowed
* through) */
- unsigned int device_hides_wep:1;
+#define IEEE80211_HW_DEVICE_HIDES_WEP (12)
/* Whether RX frames passed to ieee80211_rx() include FCS in the end */
- unsigned int rx_includes_fcs:1;
+#define IEEE80211_HW_RX_INCLUDES_FCS (13)
/* Some wireless LAN chipsets buffer broadcast/multicast frames for
* power saving stations in the hardware/firmware and others rely on
@@ -457,18 +457,19 @@ struct ieee80211_hw {
* configure the IEEE 802.11 upper layer to buffer broadcast/multicast
* frames when there are power saving stations so that low-level driver
* can fetch them with ieee80211_get_buffered_bc(). */
- unsigned int host_broadcast_ps_buffering:1;
+#define IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING (14)
- unsigned int wep_include_iv:1;
- unsigned int data_nullfunc_ack:1; /* will data nullfunc frames get
proper
- * TX status callback */
+#define IEEE80211_HW_WEP_INCLUDE_IV (15)
+
+ /* will data nullfunc frames get proper TX status callback */
+#define IEEE80211_HW_DATA_NULLFUNC_ACK (16)
/* Force software encryption for TKIP packets if WMM is enabled. */
- unsigned int no_tkip_wmm_hwaccel:1;
+#define IEEE80211_HW_NO_TKIP_WMM_HWACCEL (17)
/* set if the payload needs to be padded at even boundaries after the
* header */
- unsigned int extra_hdr_room:1;
+#define IEEE80211_HW_EXTRA_HDR_ROOM (18)
/* Some devices handle Michael MIC internally and do not include MIC in
* the received packets passed up. device_strips_mic must be set
@@ -476,15 +477,17 @@ struct ieee80211_hw {
* be still set in the IEEE 802.11 header with this option unlike with
* the device_hides_wep configuration option.
*/
- unsigned int device_strips_mic:1;
+#define IEEE80211_HW_DEVICE_STRIPS_MIC (19)
/* Device is capable of performing full monitor mode even during
* normal operation. */
- unsigned int monitor_during_oper:1;
+#define IEEE80211_HW_MONITOR_DURING_OPER (110)
/* Set if the low-level driver supports skb fraglist (NETIF_F_FRAGLIST),
* i.e. more than one skb per frame */
- unsigned int fraglist:1;
+#define IEEE80211_HW_FRAGLIST (111)
+
+ u32 flags; /* hardware flags defined above */
/* This is the time in us to change channels
*/
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
@@ -3838,9 +3838,10 @@ static int __devinit bcm43xx_init_one(st
goto out;
ieee-version = IEEE80211_VERSION;
ieee-name =
[take3 2/5] d80211: remove bitfields from ieee80211_tx_status
Both one-bit bitfields have been subsumed into the new 'flags'
structure member and the new IEEE80211_TX_STATUS_* definitions.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/include/net/d80211.h
===
--- wireless-dev.orig/include/net/d80211.h
+++ wireless-dev/include/net/d80211.h
@@ -209,8 +209,10 @@ struct ieee80211_tx_status {
/* copied ieee80211_tx_control structure */
struct ieee80211_tx_control control;
- unsigned int tx_filtered:1;
- unsigned int ack:1; /* whether the TX frame was ACKed */
+#define IEEE80211_TX_STATUS_TX_FILTERED(10)
+#define IEEE80211_TX_STATUS_ACK(11) /* whether the TX frame
was ACKed */
+ u32 flags; /* tx staus flags defined above */
+
int ack_signal; /* measured signal strength of the ACK frame */
int excessive_retries;
int retry_count;
Index: wireless-dev/drivers/net/wireless/d80211/adm8211/adm8211.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/adm8211/adm8211.c
+++ wireless-dev/drivers/net/wireless/d80211/adm8211/adm8211.c
@@ -426,12 +426,14 @@ static void adm8211_interrupt_tci(struct
if (status TDES0_STATUS_ES) {
stats-tx_errors++;
- priv-tx_buffers[entry].tx_status.ack = 0;
+ priv-tx_buffers[entry].tx_status.flags =
+ ~IEEE80211_TX_STATUS_ACK;
if (status (TDES0_STATUS_TUF | TDES0_STATUS_TRO))
stats-tx_fifo_errors++;
} else
- priv-tx_buffers[entry].tx_status.ack = 1;
+ priv-tx_buffers[entry].tx_status.flags |=
+ IEEE80211_TX_STATUS_ACK;
pci_unmap_single(priv-pdev, priv-tx_buffers[entry].mapping,
priv-tx_buffers[entry].skb-len,
PCI_DMA_TODEVICE);
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
@@ -1122,7 +1122,8 @@ void bcm43xx_dma_handle_txstatus(struct
* status of the transmission.
* Some fields of txstat are already filled in dma_tx().
*/
- meta-txstat.ack = status-acked;
+ if (status-acked)
+ meta-txstat.flags |= IEEE80211_TX_STATUS_ACK;
meta-txstat.retry_count = status-frame_count - 1;
ieee80211_tx_status_irqsafe(bcm-net_dev, meta-skb,
(meta-txstat));
/* skb is freed by ieee80211_tx_status_irqsafe() */
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_pio.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_pio.c
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_pio.c
@@ -500,7 +500,8 @@ void bcm43xx_pio_handle_txstatus(struct
queue-tx_devq_packets--;
queue-tx_devq_used -= (packet-skb-len + phy-txhdr_size);
- packet-txstat.ack = status-acked;
+ if (status-acked)
+ packet-txstat.flags |= IEEE80211_TX_STATUS_ACK;
packet-txstat.retry_count = status-frame_count - 1;
ieee80211_tx_status_irqsafe(bcm-net_dev, packet-skb,
(packet-txstat));
Index: wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
+++ wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
@@ -1741,10 +1741,11 @@ static void rt2400pci_txdone(void *data)
ack = rt2x00_get_field32(txd-word0, TXD_W0_ACK);
+ entry-tx_status.flags = 0;
/*
-* TODO: How can te below field be set correctly?
+* TODO: How can bit IEEE80211_TX_STATUS_TX_FILTERED of
+* entry-tx_status.flags be set correctly?
*/
- entry-tx_status.tx_filtered = 0;
entry-tx_status.queue_length = ring-stats.limit;
entry-tx_status.queue_number = entry-tx_status.control.queue;
@@ -1756,11 +1757,10 @@ static void rt2400pci_txdone(void *data)
* was succesfull.
*/
tx_status = rt2x00_get_field32(txd-word0, TXD_W0_RESULT);
- entry-tx_status.ack = 0;
entry-tx_status.excessive_retries = 0;
if (ack (tx_status == TX_SUCCESS ||
Re: [take3 0/5] d80211: remove bitfields from include/net/d80211.h
On Wed, Oct 25, 2006 at 11:42:44AM -0700, David Kimdon wrote: Continue d80211 bitfield removal. In general, compilers have difficulty generating efficient code for bitfields. This patchset removes all bitfields from include/net/d80211.h. I converted the 1 bit bitfields into a bit in a u32/u16 or u8 flags structure member. Larger bitfields I converted into their u8/u16/whatever equivalent. For bit flags, usually it is best to use up to 32 bits of an unsigned long, which guarantees that you use a machine integer for all platforms. 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: e100: Wait for PHY reset to complete?
Anders Grafstrom [EMAIL PROTECTED] : [...] I'm thinking something like this patch. I do not have the spec for the max duration at hand but it makes sense. Can you: - decrease the duration of each sleep and increase the count of iterations - put the break on a line of its own - add a Signed-off-by: Foo Bar [EMAIL PROTECTED] line - Cc: [EMAIL PROTECTED] and Auke Kok [EMAIL PROTECTED] -- Ueimor - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take3 0/5] d80211: remove bitfields from include/net/d80211.h
On Wed, Oct 25, 2006 at 03:01:29PM -0400, Jeff Garzik wrote: On Wed, Oct 25, 2006 at 11:42:44AM -0700, David Kimdon wrote: Continue d80211 bitfield removal. In general, compilers have difficulty generating efficient code for bitfields. This patchset removes all bitfields from include/net/d80211.h. I converted the 1 bit bitfields into a bit in a u32/u16 or u8 flags structure member. Larger bitfields I converted into their u8/u16/whatever equivalent. For bit flags, usually it is best to use up to 32 bits of an unsigned long, which guarantees that you use a machine integer for all platforms. That is how I originally had the patch, but then had a question about increasing structure size so I dropped flags to u16 or u8 for structures that were made larger by the bitfield removal. For the key_conf bitfields size doesn't matter much. For the tx_control bitfields size matters a bit more since it is needed per-packets and dirvers currently need to store a copy to pass to the tx complete handler. Thoughts? David - 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: [take3 0/5] d80211: remove bitfields from include/net/d80211.h
On Wed, Oct 25, 2006 at 12:17:02PM -0700, David Kimdon wrote: That is how I originally had the patch, but then had a question about increasing structure size so I dropped flags to u16 or u8 for structures that were made larger by the bitfield removal. On non-x86 platforms, u16 and u8 generate shitty code too. Not as shitty as bitfields, but still shitty. 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: tg3 driver fails with on-board BCM95789 NICS (GigaByte GA-7VCSV)
On 10/25/06, Michael Chan [EMAIL PROTECTED] wrote: This confirms that it's some kind of interrupt problem as David had suggested, at least on eth2. You can try booting with noapic to see if it works if you haven't got the patch from Adrian Bunk yet. No joy. Here's the dmesg after boot w/ noapic, modprobe tg3 and ifconfig eth1 up ifconfig eth2 up: tg3.c:v3.65 (August 07, 2006) PCI: Found IRQ 11 for device :08:00.0 PCI: Sharing IRQ 11 with :00:00.0 PCI: Sharing IRQ 11 with :00:02.0 PCI: Sharing IRQ 11 with :00:03.0 PCI: Sharing IRQ 11 with :00:1c.1 PCI: Sharing IRQ 11 with :01:00.0 PCI: Sharing IRQ 11 with :02:00.0 PCI: Sharing IRQ 11 with :03:00.0 PCI: Sharing IRQ 11 with :05:01.0 PCI: Sharing IRQ 11 with :0b:01.0 PCI: Setting latency timer of device :08:00.0 to 64 eth1: Tigon3 [partno(BCM95789) rev 4101 PHY(5750)] (PCI Express) 10/100/1000BaseT Ethernet 00:16:e6:80:b1:3e eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] eth1: dma_rwctrl[7618] dma_mask[64-bit] PCI: Setting latency timer of device :09:00.0 to 64 eth2: Tigon3 [partno(BCM95789) rev 4101 PHY(5750)] (PCI Express) 10/100/1000BaseT Ethernet 00:16:e6:80:b1:3f eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] eth2: dma_rwctrl[7618] dma_mask[64-bit] tg3: eth1: Link is up at 1000 Mbps, full duplex. tg3: eth1: Flow control is on for TX and on for RX. tg3: eth2: Link is up at 1000 Mbps, full duplex. tg3: eth2: Flow control is on for TX and on for RX. irq 9: nobody cared (try booting with the irqpoll option) [c013d41a] __report_bad_irq+0x2a/0x8f [c013d50f] note_interrupt+0x76/0xef [c013cbc3] __do_IRQ+0xf0/0xfd [c0105515] do_IRQ+0x31/0x69 [c010387e] common_interrupt+0x1a/0x20 [c0120e11] __do_softirq+0x63/0xeb [c0120ed3] do_softirq+0x3a/0x3c [c010551a] do_IRQ+0x36/0x69 [c010387e] common_interrupt+0x1a/0x20 [c0124e5b] del_timer_sync+0x1/0x1d [c0381998] schedule_timeout+0x60/0xaa [c01260eb] process_timeout+0x0/0x9 [c01735ac] do_select+0x1cc/0x349 [c0173292] __pollwait+0x0/0x69 [c011644e] default_wake_function+0x0/0x12 [c011644e] default_wake_function+0x0/0x12 [c011644e] default_wake_function+0x0/0x12 [c011644e] default_wake_function+0x0/0x12 [c011644e] default_wake_function+0x0/0x12 [c011644e] default_wake_function+0x0/0x12 [c035609e] fn_hash_lookup+0xb3/0xbc [c035609e] fn_hash_lookup+0xb3/0xbc [c021e8a0] copy_to_user+0x42/0x5c [c02efdf2] memcpy_toiovec+0x4a/0x5f [c02f03e7] skb_copy_datagram_iovec+0x50/0x20c [c02f02f6] skb_recv_datagram+0xbb/0xce [c02ed49c] kfree_skbmem+0x61/0x86 [c0349ced] udp_recvmsg+0x1ca/0x251 [c02ec6dc] sock_common_recvmsg+0x57/0x72 [c02e870d] sock_recvmsg+0x104/0x11e [c021e908] copy_from_user+0x4e/0x82 [c0173962] core_sys_select+0x239/0x3b1 [c01303e4] autoremove_wake_function+0x0/0x57 [c021e8a0] copy_to_user+0x42/0x5c [c02e7fb9] move_addr_to_user+0x5c/0x67 [c02e9d1d] sys_recvfrom+0x120/0x162 [f8a979d8] tg3_rx+0x13d/0x3f3 [tg3] [f8a9371e] tg3_restart_ints+0x23/0x87 [tg3] [c0173b7e] sys_select+0xa4/0x1be [c0128b8d] sys_rt_sigprocmask+0x82/0x10c [c0102ef7] syscall_call+0x7/0xb handlers: [f8a98093] (tg3_interrupt_tagged+0x0/0xc2 [tg3]) Disabling IRQ #9 tg3: eth1: Link is down. tg3: eth1: Link is up at 1000 Mbps, full duplex. tg3: eth1: Flow control is on for TX and on for RX. tg3: eth2: Link is down. tg3: eth2: Link is up at 1000 Mbps, full duplex. tg3: eth2: Flow control is on for TX and on for RX. irq 9: nobody cared (try booting with the irqpoll option) [c013d41a] __report_bad_irq+0x2a/0x8f [c013d50f] note_interrupt+0x76/0xef [c013cbc3] __do_IRQ+0xf0/0xfd [c0105515] do_IRQ+0x31/0x69 [c010e522] smp_apic_timer_interrupt+0x69/0x75 [c010387e] common_interrupt+0x1a/0x20 [c012007b] sys_setitimer+0xaa/0xb7 [c013ca92] handle_IRQ_event+0x1e/0x5f [c0107730] mask_and_ack_8259A+0x1d/0xde [c013cb61] __do_IRQ+0x8e/0xfd [c0105515] do_IRQ+0x31/0x69 [c010e522] smp_apic_timer_interrupt+0x69/0x75 [c010387e] common_interrupt+0x1a/0x20 [c0120e11] __do_softirq+0x63/0xeb [c0120ed3] do_softirq+0x3a/0x3c [c010551a] do_IRQ+0x36/0x69 [c010387e] common_interrupt+0x1a/0x20 [c0380ee3] schedule+0x3f7/0x741 [c03819e0] schedule_timeout+0xa8/0xaa [c0120e87] __do_softirq+0xd9/0xeb [c0130322] prepare_to_wait_exclusive+0x20/0x68 [c02f01f9] wait_for_packet+0xf5/0x137 [c01303e4] autoremove_wake_function+0x0/0x57 [c01303e4] autoremove_wake_function+0x0/0x57 [c02f02d0] skb_recv_datagram+0x95/0xce [c036dcdf] packet_recvmsg+0x6b/0x1b3 [c02e870d] sock_recvmsg+0x104/0x11e [f8a97d95] tg3_poll+0x107/0x1b6 [tg3] [c0121124] tasklet_action+0x76/0xcc [c01303e4] autoremove_wake_function+0x0/0x57 [c021e8a0] copy_to_user+0x42/0x5c [c02e7fb9] move_addr_to_user+0x5c/0x67 [c02e9ce1] sys_recvfrom+0xe4/0x162 [c014e48a] do_no_page+0x1eb/0x31a [c021e8a0] copy_to_user+0x42/0x5c [c02ec5f8] sock_get_timestamp+0x4a/0x7d [c02e8dee] sock_ioctl+0xb8/0x1b6 [c02ea59a] sys_socketcall+0x1bc/0x256 [c0102ef7] syscall_call+0x7/0xb handlers: [f8a98093] (tg3_interrupt_tagged+0x0/0xc2 [tg3])
RE: about 802.11i IBSS support
One area that needs work is the 802.11 qdisc - there is no provision in the current implementation for queueing certain frames because the 802.11 link is not ready to traqnsmit them yet, while letting other frames through. E.G. for normal client mode links it would be nice for the qdisc to allow management frames and EAPOL frames to an AP through while mid roam to another AP - but to queue other data frames until EAPOL has sucessfully completed. In the IBSS case a similar mechanism could queue data frames sent to a particular destination, until a key has been negociated with that destination. Indeed if the mechanism is generic the client mode case should be a subset of the IBSS case. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jouni Malinen Sent: Wednesday, October 25, 2006 8:48 AM To: Hong Liu Cc: Jiri Benc; netdev Subject: Re: about 802.11i IBSS support On Wed, Oct 25, 2006 at 04:54:41PM +0800, Hong Liu wrote: I am reading the 802.11i IBSS spec and trying to find if it is OK to add patches to d80211 to support this feature. Large parts of this will be outside d80211, but yes, I think d80211 should be made ready to support this (mainly in the multiple group keys area). When a STA (say S1) joins in an IBSS network with N STAs, it must negotiate keys with all N STAs. I don't think it is required to negotiate keys with all STAs of the network unless it actually needs to communicate with them, i.e., there may be cases where it is not needed to send or receive data from some of the nodes. We need the following parts to make 802.11i IBSS work: 1. for the d80211 part: I don't think there will be much efforts. We may add a group key to each sta_info for decrypting multicast data from that STA. And in RX path, we need to add code to select the correct group key for decryption. And also we need to store our own group key used to send multicast data to others. This will also include looking into how different WLAN chipsets have implemented (or will implement) hardware acceleration for such a case. In addition, there will likely be need for some new kernel-to-userspace events to notify supplicant/authenticator that communication with a new target is needed. I don't think the standard has strict requirements on how this is done and there may be different preferences based on the application, so adding a generic mechanism for this would be nice. 2. wpa_supplicant: this is the big part, we need to implement the authenticator in it. Not sure how much efforts needed? This is on my to-do list for wpa_supplicant/hostapd 0.6 branch where it will be possible to link in part of wpa_supplicant and hostapd together into a single program. In other words, the authenticator code (both IEEE 802.1X/EAPOL and WPA/WPA2) will be available from hostapd. -- 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 - 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: e100: Wait for PHY reset to complete?
Francois Romieu wrote: Anders Grafstrom [EMAIL PROTECTED] : [...] I'm thinking something like this patch. I do not have the spec for the max duration at hand but it makes sense. Can you: - decrease the duration of each sleep and increase the count of iterations - put the break on a line of its own - add a Signed-off-by: Foo Bar [EMAIL PROTECTED] line - Cc: [EMAIL PROTECTED] and Auke Kok [EMAIL PROTECTED] I'm already checking out specs, which, for 8255x devices, are available on http://e1000.sf.net/ . Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e100: Wait for PHY reset to complete?
Auke Kok wrote: Francois Romieu wrote: Anders Grafstrom [EMAIL PROTECTED] : [...] I'm thinking something like this patch. I do not have the spec for the max duration at hand but it makes sense. Can you: - decrease the duration of each sleep and increase the count of iterations - put the break on a line of its own - add a Signed-off-by: Foo Bar [EMAIL PROTECTED] line - Cc: [EMAIL PROTECTED] and Auke Kok [EMAIL PROTECTED] I'm already checking out specs, which, for 8255x devices, are available on http://e1000.sf.net/ . okay, I don't think this is needed at all: Allthough the spec itself didn't talk about phy reset times, I've ran this patch with some debugging output on a few boxes and did some speed/duplex settings, and the PHY reset returned succesfull after the very first mdio_read, which is before any msleep(10) is executed. That is also expected behaviour. I think you might be confusing this with a MAC reset, which has a documented 10usec timeout (see 8255x developers manual). The driver already adheres to this by doing a 20usec delay after software/selective resets. which gets us back to the original problem: how did your driver end up in loopback mode? (and, how did you figure out that it did??). Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: about 802.11i IBSS support
On Wed, 2006-10-25 at 08:48 -0700, Jouni Malinen wrote: 1. for the d80211 part: I don't think there will be much efforts. We may add a group key to each sta_info for decrypting multicast data from that STA. And in RX path, we need to add code to select the correct group key for decryption. And also we need to store our own group key used to send multicast data to others. This will also include looking into how different WLAN chipsets have implemented (or will implement) hardware acceleration for such a case. For bcm43xx, you can use any key for TX. At RX, the mac address of the sender is used to look up which key to use (broadly spoken). But if the frame is multicast, bcm43xx can only use the 4 default keys if enabled. That said, we're recently started to reverse engineer the firmware and I can see that it should be trivial to also do a mac address matching for multicast frames and use different keys then. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH] s2io: add PCI error recovery support
On Wed, Oct 25, 2006 at 10:11:24AM -0500, Linas Vepstas wrote:
Also we have to add following if statement in beginning of s2io_isr().
Done, below,
If it is ok to do BAR0 read/write in error_detected() then patch is OK.
I re-wrote that section to avoid doing I/O. It seems to work well,
and generates a few less messages in the process. New, improved patch
below, please ack and send upstream if you like it.
--linas
This patch adds PCI error recovery support to the
s2io 10-Gigabit ethernet device driver.
Tested, seems to work well.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: Raghavendra Koushik [EMAIL PROTECTED]
Cc: Ananda Raju [EMAIL PROTECTED]
Cc: Wen Xiong [EMAIL PROTECTED]
drivers/net/s2io.c | 103 +
drivers/net/s2io.h |5 ++
2 files changed, 108 insertions(+)
Index: linux-2.6.19-rc1-git11/drivers/net/s2io.c
===
--- linux-2.6.19-rc1-git11.orig/drivers/net/s2io.c 2006-10-25
14:09:47.0 -0500
+++ linux-2.6.19-rc1-git11/drivers/net/s2io.c 2006-10-25 15:18:25.0
-0500
@@ -434,11 +434,18 @@ static struct pci_device_id s2io_tbl[] _
MODULE_DEVICE_TABLE(pci, s2io_tbl);
+static struct pci_error_handlers s2io_err_handler = {
+ .error_detected = s2io_io_error_detected,
+ .slot_reset = s2io_io_slot_reset,
+ .resume = s2io_io_resume,
+};
+
static struct pci_driver s2io_driver = {
.name = S2IO,
.id_table = s2io_tbl,
.probe = s2io_init_nic,
.remove = __devexit_p(s2io_rem_nic),
+ .err_handler = s2io_err_handler,
};
/* A simplifier macro used both by init and free shared_mem Fns(). */
@@ -4171,6 +4178,11 @@ static irqreturn_t s2io_isr(int irq, voi
mac_info_t *mac_control;
struct config_param *config;
+ if ((sp-pdev-error_state != pci_channel_io_normal)
+(sp-pdev-error_state != 0)) {
+ return IRQ_HANDLED;
+ }
+
atomic_inc(sp-isr_cnt);
mac_control = sp-mac_control;
config = sp-config;
@@ -7564,3 +7576,94 @@ static void lro_append_pkt(nic_t *sp, lr
sp-mac_control.stats_info-sw_stat.clubbed_frms_cnt++;
return;
}
+
+/**
+ * s2io_io_error_detected - called when PCI error is detected
+ * @pdev: Pointer to PCI device
+ * @state: The current pci conneection state
+ *
+ * This function is called after a PCI bus error affecting
+ * this device has been detected.
+ */
+static pci_ers_result_t s2io_io_error_detected(struct pci_dev *pdev,
pci_channel_state_t state)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ nic_t *sp = netdev-priv;
+
+ netif_device_detach(netdev);
+
+ if (netif_running(netdev)) {
+ unsigned long flags;
+
+ /* The folowing is an abreviated subset of the
+* steps taken by s2io_card_down(), avoiding
+* steps that touch the card itself.
+*/
+ del_timer_sync(sp-alarm_timer);
+ atomic_set(sp-card_state, CARD_DOWN);
+
+ /* Kill tasklet. */
+ tasklet_kill(sp-task);
+
+ /* Free all Tx buffers */
+ spin_lock_irqsave(sp-tx_lock, flags);
+ free_tx_buffers(sp);
+ spin_unlock_irqrestore(sp-tx_lock, flags);
+
+ /* Free all Rx buffers */
+ spin_lock_irqsave(sp-rx_lock, flags);
+ free_rx_buffers(sp);
+ spin_unlock_irqrestore(sp-rx_lock, flags);
+
+ clear_bit(0, (sp-link_state));
+ sp-device_close_flag = TRUE; /* Device is shut down. */
+ }
+ pci_disable_device(pdev);
+
+ return PCI_ERS_RESULT_NEED_RESET;
+}
+
+/**
+ * s2io_io_slot_reset - called after the pci bus has been reset.
+ * @pdev: Pointer to PCI device
+ *
+ * Restart the card from scratch, as if from a cold-boot.
+ */
+static pci_ers_result_t s2io_io_slot_reset(struct pci_dev *pdev)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ nic_t *sp = netdev-priv;
+
+ if (pci_enable_device(pdev)) {
+ printk(KERN_ERR s2io: Cannot re-enable PCI device after
reset.\n);
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+
+ pci_set_master(pdev);
+ s2io_reset(sp);
+
+ return PCI_ERS_RESULT_RECOVERED;
+}
+
+/**
+ * s2io_io_resume - called when traffic can start flowing again.
+ * @pdev: Pointer to PCI device
+ *
+ * This callback is called when the error recovery driver tells us that
+ * its OK to resume normal operation.
+ */
+static void s2io_io_resume(struct pci_dev *pdev)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ nic_t *sp = netdev-priv;
+
+ if (netif_running(netdev)) {
+ if (s2io_card_up(sp)) {
+ printk(KERN_ERR s2io: can't bring device back up after
reset\n);
+
Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
On Wed, 2006-10-25 at 13:43 -0400, Luis R. Rodriguez wrote: I guess my hope was that d80211 would just be more than a softmac implementation. When I hear wireless stack I don't think softmac implementation, I think a robust set of headers and device definitions which all wireless devices can share. Not just that, a bunch of library functions for example for crypto would be nice too. That's part of why I've been proposing that the tkip stuff be library functions that the drivers can call if required, instead of the bitfields. Currently, there's lot of top-down stuff in d80211, it does things which depend on flags and then instructs the driver to do something. This is good for a bunch of things, but in some cases where devices vary wildly it may be better to go for library functions instead. IMHO the TKIP key computation is such a case, it's trivial for a driver to call phase1 and phase2 when required. Also I thought we'd ditch WE as it seems we keep fixing it with gum (as seen by Linville's latest ABI compatibility fix). Well, that was sort of necessary. If that wasn't the case then I'm suggesting it -- can we consider ditching WE? Well, no. We can make it a second-class citizen like I did with the cfg80211 work where I made it just one userspace interface for cfg80211 which admittedly sometimes strange behaviour, but it's still there and current operations should still work with it (and I'd consider not working a bug except if userspace never calls 'commit' and expects things to work) I'd say lets just go for a userspace MLME as its already written but I seriously think we need to ditch replace WE first. It seems no one has a plan on what to do though. - Jiri's trying to fix the SMP issues. That's great. - Jiri also would like to expand ieee80211_conf.c, the stuff I started for cfg80211 - I'd like to see a header cleanup, it's necessary. Part of the problem here is all the sub-ioctl WE foo. Clean that up by moving them into cfg80211 as required, there's basically one user, wpa_supplicant (and maybe hostapd), screw the others if there are any - fix people's minds to not expect a perfect solution immediately but accept something that can be expanded on later. I think we need to accept some breakage in our development trees to get anywhere at all. Actually, the last point should be first. Enough rant from me for today, johannes signature.asc Description: This is a digitally signed message part
Re: e100: Wait for PHY reset to complete?
Auke Kok [EMAIL PROTECTED] : [...] okay, I don't think this is needed at all: Allthough the spec itself didn't talk about phy reset times, I've ran this patch with some debugging output on a few boxes and did some speed/duplex settings, and the PHY reset returned succesfull after the very first mdio_read, which is before any msleep(10) is executed. That is also expected behaviour. Would it be expected as well that the PHY has performed reset before the second mdio_write hits it when the mdio_read is not there at all ? -- Ueimor - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
TCP congestion graphs
I ran some congestion window tests against 2.6.19-rc3. For congestion window graphs see: http://developer.osdl.org/shemminger/tcp/2.6.19-rc3/ The connection was a single flow with a 500ms RTT and a 100Mbit slowest link speed. BIC OK CUBIC OK (after patch) HIGHSPEED BROKEN? HTCPOK RENOOK (massive overshoot) SCALEABLE OK VEGAS OK (no better than Reno) VENOSame as Reno? WESTWOODOvershoot then low window Highspeed has something wrong (test glitch?) Westwood behaves poorly Veno seems no better than either Reno or Vegas in this case. The end systems were from latest git. The netem bridge is using 2.6.18-rt with a patch to netem to use hrtimers. iperf was modified to allow easy selection of congestion control. -- 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
[RFC] tcp: setsockopt congestion control autoload
If user asks for a congestion control type with setsockopt() then it
may be available as a module not included in the kernel already.
It should be autoloaded if needed. This is done already when
the default selection is change with sysctl, but not when application
requests via sysctl.
Only reservation is are there any bad security implications from this?
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- orig/net/ipv4/tcp_cong.c2006-10-25 13:55:34.0 -0700
+++ new/net/ipv4/tcp_cong.c 2006-10-25 13:58:39.0 -0700
@@ -153,9 +153,19 @@
rcu_read_lock();
ca = tcp_ca_find(name);
+ /* no change asking for existing value */
if (ca == icsk-icsk_ca_ops)
goto out;
+#ifdef CONFIG_KMOD
+ /* not found attempt to autoload module */
+ if (!ca) {
+ rcu_read_unlock();
+ request_module(tcp_%s, name);
+ rcu_read_lock();
+ ca = tcp_ca_find(name);
+ }
+#endif
if (!ca)
err = -ENOENT;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TCP congestion graphs
Not sure why the slow start for cubic is slower than the others. We will check on this. - Original Message - From: Stephen Hemminger [EMAIL PROTECTED] To: Douglas Leith [EMAIL PROTECTED]; Sangtae Ha [EMAIL PROTECTED] Cc: netdev@vger.kernel.org Sent: Wednesday, October 25, 2006 2:02 PM Subject: TCP congestion graphs I ran some congestion window tests against 2.6.19-rc3. For congestion window graphs see: http://developer.osdl.org/shemminger/tcp/2.6.19-rc3/ The connection was a single flow with a 500ms RTT and a 100Mbit slowest link speed. BIC OK CUBIC OK (after patch) HIGHSPEED BROKEN? HTCP OK RENO OK (massive overshoot) SCALEABLE OK VEGAS OK (no better than Reno) VENO Same as Reno? WESTWOOD Overshoot then low window Highspeed has something wrong (test glitch?) Westwood behaves poorly Veno seems no better than either Reno or Vegas in this case. The end systems were from latest git. The netem bridge is using 2.6.18-rt with a patch to netem to use hrtimers. iperf was modified to allow easy selection of congestion control. -- 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 - 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] d80211: switch crypto to use block ciphers
The purpose of this patch is to fix the compile-time warnings usch as:
warning: 'crypto_cipher_encrypt' is deprecated (declared at
include/linux/crypto.h:842)
I have tested static WEP and it still works after this change.
AECS/CCM and TKIP I am assuming work as well.
I don't actually know the implications of that first hunk where we do
arc4 - ecb(arc4). I look though the various commits by Herbert
Xu and that appeared to be the right thing.
Hopefully someone who understands this better than I can review the
change.
Thanks,
David
--
Switch d80211 software crypto to use the block cipher API.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/wep.c
===
--- wireless-dev.orig/net/d80211/wep.c
+++ wireless-dev/net/d80211/wep.c
@@ -26,7 +26,8 @@ int ieee80211_wep_init(struct ieee80211_
/* start WEP IV from a random value */
get_random_bytes(local-wep_iv, WEP_IV_LEN);
- local-wep_tfm = crypto_alloc_tfm(arc4, 0);
+ local-wep_tfm = crypto_alloc_blkcipher(ecb(arc4), 0,
+ CRYPTO_ALG_ASYNC);
if (!local-wep_tfm)
return -ENOMEM;
@@ -35,7 +36,7 @@ int ieee80211_wep_init(struct ieee80211_
void ieee80211_wep_free(struct ieee80211_local *local)
{
- crypto_free_tfm(local-wep_tfm);
+ crypto_free_blkcipher(local-wep_tfm);
}
static inline int ieee80211_wep_weak_iv(u32 iv, int keylen)
@@ -116,20 +117,21 @@ void ieee80211_wep_remove_iv(struct ieee
/* Perform WEP encryption using given key. data buffer must have tailroom
* for 4-byte ICV. data_len must not include this ICV. Note: this function
* does _not_ add IV. data = RC4(data | CRC32(data)) */
-void ieee80211_wep_encrypt_data(struct crypto_tfm *tfm, u8 *rc4key,
+void ieee80211_wep_encrypt_data(struct crypto_blkcipher *tfm, u8 *rc4key,
size_t klen, u8 *data, size_t data_len)
{
+ struct blkcipher_desc desc = { .tfm = tfm };
struct scatterlist sg;
__le32 *icv;
icv = (__le32 *)(data + data_len);
*icv = cpu_to_le32(~crc32_le(~0, data, data_len));
- crypto_cipher_setkey(tfm, rc4key, klen);
+ crypto_blkcipher_setkey(tfm, rc4key, klen);
sg.page = virt_to_page(data);
sg.offset = offset_in_page(data);
sg.length = data_len + WEP_ICV_LEN;
- crypto_cipher_encrypt(tfm, sg, sg, sg.length);
+ crypto_blkcipher_encrypt(desc, sg, sg, sg.length);
}
@@ -183,17 +185,18 @@ int ieee80211_wep_encrypt(struct ieee802
/* Perform WEP decryption using given key. data buffer includes encrypted
* payload, including 4-byte ICV, but _not_ IV. data_len must not include ICV.
* Return 0 on success and -1 on ICV mismatch. */
-int ieee80211_wep_decrypt_data(struct crypto_tfm *tfm, u8 *rc4key,
+int ieee80211_wep_decrypt_data(struct crypto_blkcipher *tfm, u8 *rc4key,
size_t klen, u8 *data, size_t data_len)
{
+ struct blkcipher_desc desc = { .tfm = tfm };
struct scatterlist sg;
__le32 crc;
- crypto_cipher_setkey(tfm, rc4key, klen);
+ crypto_blkcipher_setkey(tfm, rc4key, klen);
sg.page = virt_to_page(data);
sg.offset = offset_in_page(data);
sg.length = data_len + WEP_ICV_LEN;
- crypto_cipher_decrypt(tfm, sg, sg, sg.length);
+ crypto_blkcipher_decrypt(desc, sg, sg, sg.length);
crc = cpu_to_le32(~crc32_le(~0, data, data_len));
if (memcmp(crc, data + data_len, WEP_ICV_LEN) != 0)
Index: wireless-dev/net/d80211/aes_ccm.c
===
--- wireless-dev.orig/net/d80211/aes_ccm.c
+++ wireless-dev/net/d80211/aes_ccm.c
@@ -16,9 +16,10 @@
#include aes_ccm.h
-static void ieee80211_aes_encrypt(struct crypto_tfm *tfm,
+static void ieee80211_aes_encrypt(struct crypto_blkcipher *tfm,
const u8 pt[16], u8 ct[16])
{
+ struct blkcipher_desc desc = { .tfm = tfm };
struct scatterlist src, dst;
src.page = virt_to_page(pt);
@@ -29,11 +30,11 @@ static void ieee80211_aes_encrypt(struct
dst.offset = offset_in_page(ct);
dst.length = AES_BLOCK_LEN;
- crypto_cipher_encrypt(tfm, dst, src, AES_BLOCK_LEN);
+ crypto_blkcipher_encrypt(desc, dst, src, AES_BLOCK_LEN);
}
-static inline void aes_ccm_prepare(struct crypto_tfm *tfm, u8 *b_0, u8 *aad,
+static inline void aes_ccm_prepare(struct crypto_blkcipher *tfm, u8 *b_0, u8
*aad,
u8 *b, u8 *s_0, u8 *a)
{
int i;
@@ -61,7 +62,7 @@ static inline void aes_ccm_prepare(struc
}
-void ieee80211_aes_ccm_encrypt(struct crypto_tfm *tfm, u8 *scratch,
+void ieee80211_aes_ccm_encrypt(struct crypto_blkcipher *tfm, u8 *scratch,
u8 *b_0, u8 *aad, u8 *data, size_t data_len,
u8 *cdata, u8
[PATCH] tcp: cubic scaling error
Doug Leith observed a discrepancy between the version of CUBIC described in the papers and the version in 2.6.18. A math error related to scaling causes Cubic to grow too slowly. Patch is from Sangtae Ha [EMAIL PROTECTED]. I validated that it does fix the problems. See the following to show behavior over 500ms 100 Mbit link. Sender (2.6.19-rc3) --- Bridge (2.6.18-rt7) --- Receiver (2.6.19-rc3) 1G [netem] 100M http://developer.osdl.org/shemminger/tcp/2.6.19-rc3/cubic-orig.png http://developer.osdl.org/shemminger/tcp/2.6.19-rc3/cubic-fix.png Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] --- a/net/ipv4/tcp_cubic.c 2006-09-25 16:25:43.0 -0700 +++ b/net/ipv4/tcp_cubic.c 2006-10-25 09:17:28.0 -0700 @@ -190,7 +190,7 @@ */ /* change the unit from HZ to bictcp_HZ */ -t = ((tcp_time_stamp + ca-delay_min - ca-epoch_start) +t = ((tcp_time_stamp + (ca-delay_min3) - ca-epoch_start) BICTCP_HZ) / HZ; if (t ca-bic_K) /* t - K */ @@ -259,7 +259,7 @@ (s32)(tcp_time_stamp - ca-epoch_start) HZ) return; - delay = tcp_time_stamp - tp-rx_opt.rcv_tsecr; + delay = (tcp_time_stamp - tp-rx_opt.rcv_tsecr)3; if (delay == 0) delay = 1; @@ -366,7 +366,7 @@ beta_scale = 8*(BICTCP_BETA_SCALE+beta)/ 3 / (BICTCP_BETA_SCALE - beta); - cube_rtt_scale = (bic_scale 3) / 10; /* 1024*c/rtt */ + cube_rtt_scale = (bic_scale * 10); /* 1024*c/rtt */ /* calculate the K for (wmax-cwnd) = c/rtt * K^3 * so K = cubic_root( (wmax-cwnd)*rtt/c ) - 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] tcp: setsockopt congestion control autoload
Stephen Hemminger wrote: If user asks for a congestion control type with setsockopt() then it may be available as a module not included in the kernel already. It should be autoloaded if needed. This is done already when the default selection is change with sysctl, but not when application requests via sysctl. Only reservation is are there any bad security implications from this? There are already a quite large number of precedents for this, I think this is one of the less questionable ones, the potential for (local) damage is limited to minimal tcp_ca_find performance impact if I don't miss anything (assuming no bugs in the modules that cause crashes or something like that). The in my opinion most questionable autoloading is in af_netlink BTW, it will autoload any netlink provider with an appropriate module alias, which could be just about anything (examples include conntrack, which has performance and other side-effects, ULOG, which in turn loads iptables, xfrm_user, connector, ...). Other autoloading is usually limited to a clear scope of what might be affected. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
David Kimdon wrote:
wme.c needs a generic fifo qdisc for each hardware queue. Switch
wme.c to use the generic fifo qdisc in net/sched/sch_fifo.c. This allows
removal of net/d80211/fifo_qdisc.c which isn't particularily tied to
IEEE 802.11 in any way.
-#define CHILD_QDISC_OPS pfifo_qdisc_ops
-
static inline int WLAN_FC_IS_QOS_DATA(u16 fc)
{
return (fc 0x8C) == 0x88;
@@ -433,7 +431,7 @@ static int wme_qdiscop_init(struct Qdisc
/* create child queues */
for (i = 0; i queues; i++) {
skb_queue_head_init(q-requeued[i]);
- q-queues[i] = qdisc_create_dflt(qd-dev, CHILD_QDISC_OPS);
+ q-queues[i] = qdisc_create_dflt(qd-dev, pfifo_qdisc_ops);
if (q-queues[i] == 0) {
q-queues[i] = noop_qdisc;
printk(KERN_ERR %s child qdisc %i creation failed,
dev-name, i);
Index: wireless-dev/net/d80211/Kconfig
===
--- wireless-dev.orig/net/d80211/Kconfig
+++ wireless-dev/net/d80211/Kconfig
@@ -3,6 +3,7 @@ config D80211
select CRYPTO
select CRYPTO_ARC4
select CRYPTO_AES
+ select NET_SCHED
pfifo_fast is available even without CONFIG_NET_SCHED, maybe
thats a better choice to avoid unnecessary bloat.
-
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: e100: Wait for PHY reset to complete?
Auke Kok wrote:
Allthough the spec itself didn't talk about phy reset times, I've ran this
patch with
some debugging output on a few boxes and did some speed/duplex settings,
and the PHY
reset returned succesfull after the very first mdio_read, which is before
any msleep(10)
is executed. That is also expected behaviour.
I think you might be confusing this with a MAC reset, which has a
documented 10usec
timeout (see 8255x developers manual). The driver already adheres to this
by doing a
20usec delay after software/selective resets.
which gets us back to the original problem: how did your driver end up in
loopback mode?
(and, how did you figure out that it did??).
This is what the 2.4.33.3 driver does:
void
e100_phy_reset(struct e100_private *bdp)
{
u16 ctrl_reg;
ctrl_reg = BMCR_RESET;
e100_mdi_write(bdp, MII_BMCR, bdp-phy_addr, ctrl_reg);
/* ieee 802.3 : The reset process shall be completed */
/* within 0.5 seconds from the settting of PHY reset bit. */
set_current_state(TASK_UNINTERRUPTIBLE);
schedule_timeout(HZ / 2);
}
And here
http://www.cs.helsinki.fi/linux/linux-kernel/2003-23/1245.html
I found this entry:
[EMAIL PROTECTED] (03/06/08 1.1218)
[e100] misc
...
* Add 1/2 second delay after PHY reset to allow link partner to
see and respond to reset, per IEEE 802.3.
I ran mii-diag when the LEDs went out and the register dump
said it was in loopback. It is somewhat difficult reproduce.
It seems to be timing dependent, something else has to occur
at the same time.
I must confess I have only seen it with the 2.6.13 kernel.
I have not been able to reproduce it with 2.6.18.
But I have found no change in the driver that would fix it so
I suspect the problem is still there.
I have tried adding debug output to see if I can read back the
RESET bit in set state, but then the problem refuses to show
so I don't think I can rule out an unfinished PHY reset.
Anders
-
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] d80211: switch crypto to use block ciphers
On Wed, Oct 25, 2006 at 03:41:50PM -0700, David Kimdon wrote:
I don't actually know the implications of that first hunk where we do
arc4 - ecb(arc4). I look though the various commits by Herbert
Xu and that appeared to be the right thing.
Basically if you encrypt/decrypt more than a block at a time and you're
using ECB then ecb(arc4) is right. So the changes to net/d80211/wep.c
are good.
If you're only encrypting/decrypting a single block then you should
use the cipher interface. So net/d80211/aes_ccm.c should do that
instead. See drivers/net/wirless/airo.c for an example of that.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB
From: Randy Dunlap [EMAIL PROTECTED] USB network drivers that use mii_*() interfaces should cause those interfaces to be built. Or depend on them, but this is what all drivers/net/ drivers do. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- drivers/usb/net/Kconfig |3 +++ 1 file changed, 3 insertions(+) --- linux-2619-rc3-pv.orig/drivers/usb/net/Kconfig +++ linux-2619-rc3-pv/drivers/usb/net/Kconfig @@ -84,6 +84,7 @@ config USB_PEGASUS config USB_RTL8150 tristate USB RTL8150 based ethernet device support (EXPERIMENTAL) depends on EXPERIMENTAL + select MII help Say Y here if you have RTL8150 based usb-ethernet adapter. Send me [EMAIL PROTECTED] any comments you may have. @@ -94,6 +95,7 @@ config USB_RTL8150 config USB_USBNET tristate Multi-purpose USB Networking Framework + select MII ---help--- This driver supports several kinds of network links over USB, with minidrivers built around a common network driver core @@ -210,6 +212,7 @@ config USB_NET_PLUSB config USB_NET_MCS7830 tristate MosChip MCS7830 based Ethernet adapters depends on USB_USBNET + select MII help Choose this option if you're using a 10/100 Ethernet USB2 adapter based on the MosChip 7830 controller. This includes --- - 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] !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB
@@ -94,6 +95,7 @@ config USB_RTL8150 config USB_USBNET tristate Multi-purpose USB Networking Framework + select MII ---help--- This driver supports several kinds of network links over USB, with minidrivers built around a common network driver core The other parts are right, this isn't. Instead, usbnet.c should #ifdef the relevant ethtool hooks according to CONFIG_MII ... since it's completely legit to use usbnet with peripherals that don't need MII. - 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/2] usbnet: use MII hooks only if CONFIG_MII is enabled
On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote: Instead, usbnet.c should #ifdef the relevant ethtool hooks according to CONFIG_MII ... since it's completely legit to use usbnet with peripherals that don't need MII. --- From: Randy Dunlap [EMAIL PROTECTED] usbnet driver should use mii_*() interfaces if they are available in the kernel (config enabled) but usbnet does not require or depend on these interfaces. Build tested with CONFIG_MII=y, m, n. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- drivers/usb/net/usbnet.c | 18 ++ 1 file changed, 18 insertions(+) --- linux-2619-rc3-pv.orig/drivers/usb/net/usbnet.c +++ linux-2619-rc3-pv/drivers/usb/net/usbnet.c @@ -47,6 +47,12 @@ #define DRIVER_VERSION 22-Aug-2005 +#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE) +#define HAVE_MII 1 +#else +#define HAVE_MII 0 +#endif + /*-*/ @@ -676,7 +682,10 @@ int usbnet_get_settings (struct net_devi if (!dev-mii.mdio_read) return -EOPNOTSUPP; +#if HAVE_MII return mii_ethtool_gset(dev-mii, cmd); +#endif + return -EOPNOTSUPP; } EXPORT_SYMBOL_GPL(usbnet_get_settings); @@ -688,7 +697,11 @@ int usbnet_set_settings (struct net_devi if (!dev-mii.mdio_write) return -EOPNOTSUPP; +#if HAVE_MII retval = mii_ethtool_sset(dev-mii, cmd); +#else + retval = -EOPNOTSUPP; +#endif /* link speed/duplex might have changed */ if (dev-driver_info-link_reset) @@ -721,9 +734,11 @@ u32 usbnet_get_link (struct net_device * if (dev-driver_info-check_connect) return dev-driver_info-check_connect (dev) == 0; +#if HAVE_MII /* if the device has mii operations, use those */ if (dev-mii.mdio_read) return mii_link_ok(dev-mii); +#endif /* Otherwise, say we're up (to avoid breaking scripts) */ return 1; @@ -753,7 +768,10 @@ int usbnet_nway_reset(struct net_device if (!dev-mii.mdio_write) return -EOPNOTSUPP; +#if HAVE_MII return mii_nway_restart(dev-mii); +#endif + return -EOPNOTSUPP; } EXPORT_SYMBOL_GPL(usbnet_nway_reset); - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB
On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote: The other parts are right, this isn't. Instead, usbnet.c should #ifdef the relevant ethtool hooks according to CONFIG_MII ... since it's completely legit to use usbnet with peripherals that don't need MII. Ugh. OK. How's this? (2 patches) (oh, OP mentioned CONFIG_PHYLIB but it's actually CONFIG_MII AFAIK) --- From: Randy Dunlap [EMAIL PROTECTED] pegasus and mcs7830 drivers use MII interfaces and should select MII in the same way that drivers/net/ drivers do. However, the MII config symbol should not be in the 10/100 Ethernet menu, so that other drivers can use (enable) it or so that users can enable it without needing to enable 10/100 Ethernet. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- drivers/net/Kconfig | 15 +++ drivers/usb/net/Kconfig |2 ++ 2 files changed, 9 insertions(+), 8 deletions(-) --- linux-2619-rc3-pv.orig/drivers/usb/net/Kconfig +++ linux-2619-rc3-pv/drivers/usb/net/Kconfig @@ -84,6 +84,7 @@ config USB_PEGASUS config USB_RTL8150 tristate USB RTL8150 based ethernet device support (EXPERIMENTAL) depends on EXPERIMENTAL + select MII help Say Y here if you have RTL8150 based usb-ethernet adapter. Send me [EMAIL PROTECTED] any comments you may have. @@ -210,6 +211,7 @@ config USB_NET_PLUSB config USB_NET_MCS7830 tristate MosChip MCS7830 based Ethernet adapters depends on USB_USBNET + select MII help Choose this option if you're using a 10/100 Ethernet USB2 adapter based on the MosChip 7830 controller. This includes --- linux-2619-rc3-pv.orig/drivers/net/Kconfig +++ linux-2619-rc3-pv/drivers/net/Kconfig @@ -145,6 +145,13 @@ config NET_SB1000 source drivers/net/arcnet/Kconfig +config MII + tristate Generic Media Independent Interface device support + help + Most ethernet controllers have MII transceiver either as an external + or internal device. It is safe to say Y or M here even if your + ethernet card lacks MII. + source drivers/net/phy/Kconfig # @@ -180,14 +187,6 @@ config NET_ETHERNET kernel: saying N will just cause the configurator to skip all the questions about Ethernet network cards. If unsure, say N. -config MII - tristate Generic Media Independent Interface device support - depends on NET_ETHERNET - help - Most ethernet controllers have MII transceiver either as an external - or internal device. It is safe to say Y or M here even if your - ethernet card lack MII. - source drivers/net/arm/Kconfig config MACE - 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: e100: Wait for PHY reset to complete?
Anders Grafström wrote:
Auke Kok wrote:
Allthough the spec itself didn't talk about phy reset times, I've ran this
patch with
some debugging output on a few boxes and did some speed/duplex settings,
and the PHY
reset returned succesfull after the very first mdio_read, which is before
any msleep(10)
is executed. That is also expected behaviour.
I think you might be confusing this with a MAC reset, which has a
documented 10usec
timeout (see 8255x developers manual). The driver already adheres to this
by doing a
20usec delay after software/selective resets.
which gets us back to the original problem: how did your driver end up in
loopback mode?
(and, how did you figure out that it did??).
This is what the 2.4.33.3 driver does:
void
e100_phy_reset(struct e100_private *bdp)
{
u16 ctrl_reg;
ctrl_reg = BMCR_RESET;
e100_mdi_write(bdp, MII_BMCR, bdp-phy_addr, ctrl_reg);
/* ieee 802.3 : The reset process shall be completed */
/* within 0.5 seconds from the settting of PHY reset bit. */
set_current_state(TASK_UNINTERRUPTIBLE);
schedule_timeout(HZ / 2);
}
And here
http://www.cs.helsinki.fi/linux/linux-kernel/2003-23/1245.html
I found this entry:
[EMAIL PROTECTED] (03/06/08 1.1218)
[e100] misc
...
* Add 1/2 second delay after PHY reset to allow link partner to
see and respond to reset, per IEEE 802.3.
I ran mii-diag when the LEDs went out and the register dump
said it was in loopback. It is somewhat difficult reproduce.
It seems to be timing dependent, something else has to occur
at the same time.
I must confess I have only seen it with the 2.6.13 kernel.
I have not been able to reproduce it with 2.6.18.
But I have found no change in the driver that would fix it so
I suspect the problem is still there.
I have tried adding debug output to see if I can read back the
RESET bit in set state, but then the problem refuses to show
so I don't think I can rule out an unfinished PHY reset.
theoretically, yes, the ieee spec PHY reset timeout is kind of silly: in no way do we
assume that we have re-negotiated link after 1/2 a second! Other code in the driver
should take care of that, and since it works I'll assume it does ;)
the mdio_read probably acts as a flush to the hardware too - masquerading problems, more
goodness. Perhaps we should do a single read in all cases and forget about the timeout
(is there an mdio_write_flush?)
Basically the timeout is wrong: a LINK reset is not a PHY reset. The PHY is back online
and ready to respond in (probably) a single clock cycle. The link can take up to 3
seconds in normal cases. Waiting for 1/2 a second does not fix anything there. Here's
where the 8255x (PHY part) spec abandons us: I don't read anything about PHY reset
timeouts in it.
Can you try to debug if your while () timeout loop is actually waiting for a significant
amount? something like adding a printk(KERN_ERR counted down to %d0 msec\n, counter);
after the entire while{} loop should show you if there is variation in the PHY reset
time needed for the PHY to be back online.
running mii-diag before the link comes back up might be causing the issue in the first
place, and certainly suggests a small race.
Have you tried to run the e100-sbit branch from jgarzik's netdev-2.6 tree? We're still
looking into merging this and I guess I should push it to -mm to have it receive some
testing
Cheers,
Auke
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
Patrick McHardy wrote:
David Kimdon wrote:
wme.c needs a generic fifo qdisc for each hardware queue. Switch
wme.c to use the generic fifo qdisc in net/sched/sch_fifo.c. This allows
removal of net/d80211/fifo_qdisc.c which isn't particularily tied to
IEEE 802.11 in any way.
-#define CHILD_QDISC_OPS pfifo_qdisc_ops
-
static inline int WLAN_FC_IS_QOS_DATA(u16 fc)
{
return (fc 0x8C) == 0x88;
@@ -433,7 +431,7 @@ static int wme_qdiscop_init(struct Qdisc
/* create child queues */
for (i = 0; i queues; i++) {
skb_queue_head_init(q-requeued[i]);
- q-queues[i] = qdisc_create_dflt(qd-dev, CHILD_QDISC_OPS);
+ q-queues[i] = qdisc_create_dflt(qd-dev, pfifo_qdisc_ops);
if (q-queues[i] == 0) {
q-queues[i] = noop_qdisc;
printk(KERN_ERR %s child qdisc %i creation failed,
dev-name, i);
Index: wireless-dev/net/d80211/Kconfig
===
--- wireless-dev.orig/net/d80211/Kconfig
+++ wireless-dev/net/d80211/Kconfig
@@ -3,6 +3,7 @@ config D80211
select CRYPTO
select CRYPTO_ARC4
select CRYPTO_AES
+ select NET_SCHED
pfifo_fast is available even without CONFIG_NET_SCHED, maybe
thats a better choice to avoid unnecessary bloat.
BTW, I noticed a few bugs while looking at the qdisc handling in
wireless-dev:
- wme_qdiscop_enqueue doesn't increment q.qlen for packets queued
to q-requeued[], which might cause upper layer code to stop
dequeueing if q.qlen reaches zero.
- classify_1d doesn't care about tc_classify return values.
tc_classify may decide to steal packets, drop them, etc. In case
of stolen packets this causes use-after-free, otherwise just
malfunctions.
- classify_1d returns res.class if it is != -1, which can never happen
(except with an empty classifier list because of the explicit
initialization, but you should check the return code) since -get()
and -bind_tcf() both return 0 for invalid classes and the classid
otherwise. There's also an off-by-one, classids start at one, so it
should return res.class - 1 (or better res.classid - 1, which is
meant to be a numerical identifier).
- wme_discop_destroy leaks classifier module references and memory
when destroying classifiers, it should use tcf_destroy()
Considering that it is possibly and may be desirable to attach a
different qdisc than the built-in multiband qdisc, it might also
make sense to split the 80211 specific classification in a seperate
classifier module to allow simple classification of management traffic
with other qdiscs.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TCP congestion graphs
On Wed, 25 Oct 2006 18:34:17 -0400 Injong Rhee [EMAIL PROTECTED] wrote: Not sure why the slow start for cubic is slower than the others. We will check on this. I think it is because cubic initializes with a ssthresh of 100, and others leave ssthresh uninitialized until the first loss. This causes cubic to change to conservative mode once it crosses the initial ssthresh. Other protocols just keep doing additive increase. My large BDP test has a 500ms delay (250ms each way) and a real 100mbit link on the last hop. Because the intermediate emulator has a large queue (10,000 packets) large growth is possible before the first loss event. There were also no other flows during this test to fill the intermediate queue. This may very well be a bogus test, I just was looking for large BDP behavior quirks. Any test without background traffic as you have argued is unrealistic. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
Pfifo_fast does not make sense because the 802.11 qdisc already
categorizes the frames based on DSCP. The better thing would be to
extract the pfifo qdisc so that it does not require NET_SCHED, but this
is more work.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Patrick McHardy
Sent: Wednesday, October 25, 2006 4:29 PM
To: David Kimdon
Cc: netdev@vger.kernel.org; John W. Linville; Jiri Benc
Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather than
d80211-specific qdisc
David Kimdon wrote:
wme.c needs a generic fifo qdisc for each hardware queue. Switch
wme.c to use the generic fifo qdisc in net/sched/sch_fifo.c. This
allows removal of net/d80211/fifo_qdisc.c which isn't particularily
tied to IEEE 802.11 in any way.
-#define CHILD_QDISC_OPS pfifo_qdisc_ops
-
static inline int WLAN_FC_IS_QOS_DATA(u16 fc) {
return (fc 0x8C) == 0x88;
@@ -433,7 +431,7 @@ static int wme_qdiscop_init(struct Qdisc
/* create child queues */
for (i = 0; i queues; i++) {
skb_queue_head_init(q-requeued[i]);
- q-queues[i] = qdisc_create_dflt(qd-dev,
CHILD_QDISC_OPS);
+ q-queues[i] = qdisc_create_dflt(qd-dev,
pfifo_qdisc_ops);
if (q-queues[i] == 0) {
q-queues[i] = noop_qdisc;
printk(KERN_ERR %s child qdisc %i creation
failed, dev-name,
i);
Index: wireless-dev/net/d80211/Kconfig
===
--- wireless-dev.orig/net/d80211/Kconfig
+++ wireless-dev/net/d80211/Kconfig
@@ -3,6 +3,7 @@ config D80211
select CRYPTO
select CRYPTO_ARC4
select CRYPTO_AES
+ select NET_SCHED
pfifo_fast is available even without CONFIG_NET_SCHED, maybe thats a
better choice to avoid unnecessary bloat.
-
To unsubscribe from this list: send the line unsubscribe netdev in the
body of a message to [EMAIL PROTECTED] More majordomo info at
http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
Simon Barber wrote: Pfifo_fast does not make sense because the 802.11 qdisc already categorizes the frames based on DSCP. The better thing would be to extract the pfifo qdisc so that it does not require NET_SCHED, but this is more work. It wouldn't really hurt though since all frames queued to a band already have the same priority, so pfifo_fast behaves similar to fifo. BTW, is there a specific reason for using DSCP? Normally Linux uses rt_tos2priority and prio2band for determining a priority for IP packets. I don't want to argue that one is better than the other, but there is some value in keeping things consistent .. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
Simon Barber wrote: Pfifo_fast does not make sense because the 802.11 qdisc already categorizes the frames based on DSCP. The better thing would be to extract the pfifo qdisc so that it does not require NET_SCHED, but this is more work. This patch should be enough to use it without NET_SCHED. You could of course also allow modular build. diff --git a/net/d80211/Kconfig b/net/d80211/Kconfig index 0f07d41..2cb79c1 100644 --- a/net/d80211/Kconfig +++ b/net/d80211/Kconfig @@ -3,6 +3,7 @@ config D80211 select CRYPTO select CRYPTO_ARC4 select CRYPTO_AES + select NET_SCH_FIFO ---help--- This option enables the hardware independent IEEE 802.11 networking stack. diff --git a/net/sched/Kconfig b/net/sched/Kconfig index 8298ea9..1d8b0dc 100644 --- a/net/sched/Kconfig +++ b/net/sched/Kconfig @@ -40,6 +40,10 @@ config NET_SCHED The available schedulers are listed in the following questions; you can say Y to as many as you like. If unsure, say N now. +config NET_SCH_FIFO + bool + default y if NET_SCHED=y + if NET_SCHED choice diff --git a/net/sched/Makefile b/net/sched/Makefile index 0f06aec..ff2d6e5 100644 --- a/net/sched/Makefile +++ b/net/sched/Makefile @@ -4,7 +4,7 @@ # obj-y := sch_generic.o -obj-$(CONFIG_NET_SCHED)+= sch_api.o sch_fifo.o sch_blackhole.o +obj-$(CONFIG_NET_SCHED)+= sch_api.o sch_blackhole.o obj-$(CONFIG_NET_CLS) += cls_api.o obj-$(CONFIG_NET_CLS_ACT) += act_api.o obj-$(CONFIG_NET_ACT_POLICE) += act_police.o @@ -14,6 +14,7 @@ obj-$(CONFIG_NET_ACT_MIRRED) += act_mirr obj-$(CONFIG_NET_ACT_IPT) += act_ipt.o obj-$(CONFIG_NET_ACT_PEDIT)+= act_pedit.o obj-$(CONFIG_NET_ACT_SIMP) += act_simple.o +obj-$(CONFIG_NET_SCH_FIFO) += sch_fifo.o obj-$(CONFIG_NET_SCH_CBQ) += sch_cbq.o obj-$(CONFIG_NET_SCH_HTB) += sch_htb.o obj-$(CONFIG_NET_SCH_HPFQ) += sch_hpfq.o
Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, Oct 26, 2006 at 03:21:10AM +0200, Patrick McHardy wrote: Considering that it is possibly and may be desirable to attach a different qdisc than the built-in multiband qdisc, it might also make sense to split the 80211 specific classification in a seperate classifier module to allow simple classification of management traffic with other qdiscs. I've been telling the wireless people this for ages... 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: about 802.11i IBSS support
On Wed, 2006-10-25 at 23:48, Jouni Malinen wrote: On Wed, Oct 25, 2006 at 04:54:41PM +0800, Hong Liu wrote: I am reading the 802.11i IBSS spec and trying to find if it is OK to add patches to d80211 to support this feature. Large parts of this will be outside d80211, but yes, I think d80211 should be made ready to support this (mainly in the multiple group keys area). When a STA (say S1) joins in an IBSS network with N STAs, it must negotiate keys with all N STAs. I don't think it is required to negotiate keys with all STAs of the network unless it actually needs to communicate with them, i.e., there may be cases where it is not needed to send or receive data from some of the nodes. This may add complexity to the implementation. If the STA wants to send broadcast data, it must distribute its group key to all other STAs, and then it can send out the packet. For RX, if it receives data from other STA it needs to find out whether it has finished key negotiation with that STA. And it can not decrypt the data until key negotiation is finished. If we negotiate keys at the beginning, things will be simple. But the cost is we may negotiating keys with STAs we may not communicate with. Thanks, Hong - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
The Wi-Fi alliance's test plans for their WMM specification are written assuming you use certain specific DSCP values. Since WMM is the only QoS mechanism that is widely used with 802.11 I followed the WMM values in the default 802.11 qdisc implementation. Most windows 802.11 drivers do the same thing. Simon -Original Message- From: Patrick McHardy [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 25, 2006 6:50 PM To: Simon Barber Cc: David Kimdon; netdev@vger.kernel.org; John W. Linville; Jiri Benc Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc Simon Barber wrote: Pfifo_fast does not make sense because the 802.11 qdisc already categorizes the frames based on DSCP. The better thing would be to extract the pfifo qdisc so that it does not require NET_SCHED, but this is more work. It wouldn't really hurt though since all frames queued to a band already have the same priority, so pfifo_fast behaves similar to fifo. BTW, is there a specific reason for using DSCP? Normally Linux uses rt_tos2priority and prio2band for determining a priority for IP packets. I don't want to argue that one is better than the other, but there is some value in keeping things consistent .. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/3] Add tsi108 On Chip Ethernet device driver support
On Mon, 2006-10-23 at 10:09, Zang Roy-r61911 wrote: On Thu, 2006-09-21 at 12:46, Jeff Garzik wrote: you should have a chip structure, that contains two structs (one for each interface/port) Jeff, I updated the code according to all your feedback and post it here http://www.spinics.net/lists/netdev/msg17120.html Any comment? Roy Jeff How about it? What's your comment? Roy - 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: about 802.11i IBSS support
It's not possible to 'negotiate keys at the beginning' - since there is no indication of a new station joining an IBSS. The first you ever know about a station joining an IBSS is when you receive a frame from that station. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hong Liu Sent: Wednesday, October 25, 2006 7:47 PM To: Jouni Malinen Cc: Jiri Benc; netdev Subject: Re: about 802.11i IBSS support On Wed, 2006-10-25 at 23:48, Jouni Malinen wrote: On Wed, Oct 25, 2006 at 04:54:41PM +0800, Hong Liu wrote: I am reading the 802.11i IBSS spec and trying to find if it is OK to add patches to d80211 to support this feature. Large parts of this will be outside d80211, but yes, I think d80211 should be made ready to support this (mainly in the multiple group keys area). When a STA (say S1) joins in an IBSS network with N STAs, it must negotiate keys with all N STAs. I don't think it is required to negotiate keys with all STAs of the network unless it actually needs to communicate with them, i.e., there may be cases where it is not needed to send or receive data from some of the nodes. This may add complexity to the implementation. If the STA wants to send broadcast data, it must distribute its group key to all other STAs, and then it can send out the packet. For RX, if it receives data from other STA it needs to find out whether it has finished key negotiation with that STA. And it can not decrypt the data until key negotiation is finished. If we negotiate keys at the beginning, things will be simple. But the cost is we may negotiating keys with STAs we may not communicate with. Thanks, Hong - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
Doing this will slow down the qdisc - it does already run an external classifier first if you install one. On typical laptops performance is not a problem, but one common usage does have problems. The performance of a wireless home gateway based on a simple linux kernel configuration (NAT, iptables, bridging) is significantly slower than a VxWorks based one. With the arrival of 802.11n improving the performance of the stack is very important. The VxWorks solution may be less flexible in terms of what it can do, but it will allow the full 802.11n bandwidth to be achieved on slower embedded CPUs than Linux does. How to improve the linux kernel networking to improve it's efficiency here is a hard problem. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Garzik Sent: Wednesday, October 25, 2006 7:39 PM To: Patrick McHardy Cc: David Kimdon; netdev@vger.kernel.org; John W. Linville; Jiri Benc Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc On Thu, Oct 26, 2006 at 03:21:10AM +0200, Patrick McHardy wrote: Considering that it is possibly and may be desirable to attach a different qdisc than the built-in multiband qdisc, it might also make sense to split the 80211 specific classification in a seperate classifier module to allow simple classification of management traffic with other qdiscs. I've been telling the wireless people this for ages... 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 - 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: Fwd: [PATCH] bcm43xx: (hopefully) fix watchdog timeouts.
On Wed, Oct 25, 2006 at 11:38:38AM +0200, Michael Buesch wrote: On Wednesday 25 October 2006 02:37, John W. Linville wrote: Michael, It looks like you have a patch that I don't have, one that moves the netif_tx_disable and spin_lock_irqsave outside of the if (badness BADNESS_LIMIT) conditional. Could you pass that one along as well, or correct this patch to match what is in Linus' tree? Well, I'm not sure who moved the tx_disable outside of the conditional. It is not needed. We only need to disable TX on the slowpath (the first branch of the if condition). It does not hurt to disable it always, though. But I will send a new patch against wireless-2.6, which only disables TX for the slowpath and fakes a TX there. But for Greg, the original patch is ok. How was the stable mailing list again? [EMAIL PROTECTED] seems to bounce. As per the MAINTAINERS file, it is [EMAIL PROTECTED] Please send this there, it will not get lost that way. thanks, greg k-h - 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
[git patches] e100, e1000 fixes
The e100 fix finally fixes the netconsole problems.
The e1000 fixes look pretty safe, but don't have hardware at the
moment to test. A non-Intel list member verified the e1000 stuff at
least works for him.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/e100.c| 10 +++--
drivers/net/e1000/e1000_ethtool.c |4 +++-
drivers/net/e1000/e1000_hw.h |6 +++--
drivers/net/e1000/e1000_main.c| 41 +
4 files changed, 42 insertions(+), 19 deletions(-)
Auke Kok:
e1000: FIX: 82542 doesn't support WoL
e1000: Increment version to 7.2.9-k4
e100: account for closed interface when shutting down
Bruce Allan:
e1000: FIX: fix wrong txdctl threshold bitmasks
Jesse Brandeburg:
e1000: FIX: don't poke at manageability registers for incompatible
adapters
e1000: FIX: Disable Packet Split for non jumbo frames
e1000: FIX: Don't limit descriptor size to 4kb for PCI-E adapters
e1000: FIX: move length adjustment due to crc stripping disabled.
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index a3a08a5..19ab344 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -2719,7 +2719,10 @@ static int e100_suspend(struct pci_dev *
struct net_device *netdev = pci_get_drvdata(pdev);
struct nic *nic = netdev_priv(netdev);
- netif_poll_disable(nic-netdev);
+#ifdef CONFIG_E100_NAPI
+ if (netif_running(netdev))
+ netif_poll_disable(nic-netdev);
+#endif
del_timer_sync(nic-watchdog);
netif_carrier_off(nic-netdev);
@@ -2763,7 +2766,10 @@ static void e100_shutdown(struct pci_dev
struct net_device *netdev = pci_get_drvdata(pdev);
struct nic *nic = netdev_priv(netdev);
- netif_poll_disable(nic-netdev);
+#ifdef CONFIG_E100_NAPI
+ if (netif_running(netdev))
+ netif_poll_disable(nic-netdev);
+#endif
del_timer_sync(nic-watchdog);
netif_carrier_off(nic-netdev);
diff --git a/drivers/net/e1000/e1000_ethtool.c
b/drivers/net/e1000/e1000_ethtool.c
index 773821e..c564adb 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -461,7 +461,8 @@ e1000_get_regs(struct net_device *netdev
regs_buff[24] = (uint32_t)phy_data; /* phy local receiver status */
regs_buff[25] = regs_buff[24]; /* phy remote receiver status */
if (hw-mac_type = e1000_82540
- hw-media_type == e1000_media_type_copper) {
+ hw-mac_type e1000_82571
+ hw-media_type == e1000_media_type_copper) {
regs_buff[26] = E1000_READ_REG(hw, MANC);
}
}
@@ -1690,6 +1691,7 @@ static int e1000_wol_exclusion(struct e1
int retval = 1; /* fail by default */
switch (hw-device_id) {
+ case E1000_DEV_ID_82542:
case E1000_DEV_ID_82543GC_FIBER:
case E1000_DEV_ID_82543GC_COPPER:
case E1000_DEV_ID_82544EI_FIBER:
diff --git a/drivers/net/e1000/e1000_hw.h b/drivers/net/e1000/e1000_hw.h
index 112447f..449a603 100644
--- a/drivers/net/e1000/e1000_hw.h
+++ b/drivers/net/e1000/e1000_hw.h
@@ -1961,9 +1961,9 @@ #define E1000_RXDCTL_WTHRESH 0x003F
#define E1000_RXDCTL_GRAN0x0100 /* RXDCTL Granularity */
/* Transmit Descriptor Control */
-#define E1000_TXDCTL_PTHRESH 0x00FF /* TXDCTL Prefetch Threshold */
-#define E1000_TXDCTL_HTHRESH 0xFF00 /* TXDCTL Host Threshold */
-#define E1000_TXDCTL_WTHRESH 0x00FF /* TXDCTL Writeback Threshold */
+#define E1000_TXDCTL_PTHRESH 0x003F /* TXDCTL Prefetch Threshold */
+#define E1000_TXDCTL_HTHRESH 0x3F00 /* TXDCTL Host Threshold */
+#define E1000_TXDCTL_WTHRESH 0x003F /* TXDCTL Writeback Threshold */
#define E1000_TXDCTL_GRAN0x0100 /* TXDCTL Granularity */
#define E1000_TXDCTL_LWTHRESH 0xFE00 /* TXDCTL Low Threshold */
#define E1000_TXDCTL_FULL_TX_DESC_WB 0x0101 /* GRAN=1, WTHRESH=1 */
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index fa84983..8d04752 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -35,7 +35,7 @@ #define DRIVERNAPI
#else
#define DRIVERNAPI -NAPI
#endif
-#define DRV_VERSION 7.2.9-k2DRIVERNAPI
+#define DRV_VERSION 7.2.9-k4DRIVERNAPI
char e1000_driver_version[] = DRV_VERSION;
static char e1000_copyright[] = Copyright (c) 1999-2006 Intel Corporation.;
@@ -699,7 +699,10 @@ #endif
phy_data);
}
- if ((adapter-en_mng_pt) (adapter-hw.mac_type e1000_82571)) {
+ if ((adapter-en_mng_pt)
+ (adapter-hw.mac_type = e1000_82540)
+ (adapter-hw.mac_type e1000_82571)
+ (adapter-hw.media_type == e1000_media_type_copper)) {
manc = E1000_READ_REG(adapter-hw, MANC);
manc |= (E1000_MANC_ARP_EN |
[RFC PATCH 2/11] pcmcia: add more IDs to hostap_cs.c
From: Dominik Brodowski [EMAIL PROTECTED] Date: Sun, 2 Jul 2006 21:21:51 +0200 Subject: [PATCH] pcmcia: add more IDs to hostap_cs.c As a replacement for the broad manufactor/card ID match we commented out because of conflicts with pcnet_cs, add two product ID matches. Signed-off-by: Dominik Brodowski [EMAIL PROTECTED] --- drivers/net/wireless/hostap/hostap_cs.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/drivers/net/wireless/hostap/hostap_cs.c b/drivers/net/wireless/hostap/hostap_cs.c index 686d895..f63909e 100644 --- a/drivers/net/wireless/hostap/hostap_cs.c +++ b/drivers/net/wireless/hostap/hostap_cs.c @@ -887,6 +887,13 @@ static struct pcmcia_device_id hostap_cs PCMCIA_DEVICE_PROD_ID123( U.S. Robotics, IEEE 802.11b PC-CARD, Version 01.02, 0xc7b8df9d, 0x1700d087, 0x4b74baa0), + PCMCIA_DEVICE_PROD_ID123( + Allied Telesyn, AT-WCL452 Wireless PCMCIA Radio, + Ver. 1.00, + 0x5cd01705, 0x4271660f, 0x9d08ee12), + PCMCIA_DEVICE_PROD_ID123( + corega, WL PCCL-11, ISL37300P, + 0xa21501a, 0x59868926, 0xc9049a39), PCMCIA_DEVICE_NULL }; MODULE_DEVICE_TABLE(pcmcia, hostap_cs_ids); -- 1.4.3 - 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 0/11] pcmcia: bugfixes for 2.6.19-rc3
Hi, The following eleven patches have all been queued in -mm for quite some time; the only change is that one suggestion by Pavel Roskin (to remove the RevA part of the new ID for hostap_cs.c) is implemented. Please let me know if there are any objections to any of these patches; if not, I'll submit them to Linus really soon now. Thanks, Dominik drivers/net/wireless/hostap/hostap_cs.c |7 +++ drivers/pcmcia/at91_cf.c| 28 +--- drivers/pcmcia/au1000_generic.c | 25 +++-- drivers/pcmcia/ds.c | 29 - drivers/pcmcia/i82092.c |9 + drivers/pcmcia/m8xx_pcmcia.c| 12 drivers/pcmcia/omap_cf.c|3 ++- drivers/pcmcia/pcmcia_ioctl.c | 11 --- drivers/pcmcia/pcmcia_resource.c|2 +- drivers/pcmcia/pd6729.c |4 drivers/pcmcia/soc_common.c |1 + drivers/pcmcia/yenta_socket.c | 22 +- 12 files changed, 105 insertions(+), 48 deletions(-) Alexey Dobriyan (2): CONFIG_PM=n slim: drivers/pcmcia/* i82092: wire up errors from pci_register_driver() Amol Lad (1): ioremap balanced with iounmap for drivers/pcmcia David Brownell (1): pcmcia: at91_cf update Dominik Brodowski (2): pcmcia: add more IDs to hostap_cs.c PCMCIA: fix __must_check warnings Jeff Garzik (1): PCMCIA: handle sysfs, PCI errors Jonathan McDowell (1): Export soc_common_drv_pcmcia_remove to allow modular PCMCIA. Kaustav Majumdar (1): pcmcia: update alloc_io_space for conflict checking for multifunction PC card Om Narasimhan (1): pcmcia: au1000_generic fix Randy Dunlap (1): pcmcia/ds: driver layer error checking pgp2xOJsdycbk.pgp Description: PGP signature
Re: [PATCH 1/2] !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB
On Wednesday 25 October 2006 4:59 pm, Randy Dunlap wrote: On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote: The other parts are right, this isn't. Instead, usbnet.c should #ifdef the relevant ethtool hooks according to CONFIG_MII ... since it's completely legit to use usbnet with peripherals that don't need MII. Ugh. OK. How's this? (2 patches) Looks about right, but ... However, the MII config symbol should not be in the 10/100 Ethernet menu, so that other drivers can use (enable) it or so that users can enable it without needing to enable 10/100 Ethernet. ... MII should still depend on ETHERNET, right? Just not limited to 10/100 Ethernet. --- linux-2619-rc3-pv.orig/drivers/net/Kconfig +++ linux-2619-rc3-pv/drivers/net/Kconfig @@ -145,6 +145,13 @@ config NET_SB1000 source drivers/net/arcnet/Kconfig +config MII + tristate Generic Media Independent Interface device support + help + Most ethernet controllers have MII transceiver either as an external + or internal device. It is safe to say Y or M here even if your + ethernet card lacks MII. + source drivers/net/phy/Kconfig # @@ -180,14 +187,6 @@ config NET_ETHERNET kernel: saying N will just cause the configurator to skip all the questions about Ethernet network cards. If unsure, say N. -config MII - tristate Generic Media Independent Interface device support - depends on NET_ETHERNET - help - Most ethernet controllers have MII transceiver either as an external - or internal device. It is safe to say Y or M here even if your - ethernet card lack MII. - source drivers/net/arm/Kconfig config MACE - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
On Wednesday 25 October 2006 4:58 pm, Randy Dunlap wrote:
On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote:
Instead, usbnet.c should #ifdef the relevant ethtool hooks
according to CONFIG_MII ... since it's completely legit to
use usbnet with peripherals that don't need MII.
I had in mind something simpler -- #ifdeffing the entire functions,
as in this patch. It looks more complicated than it is, because
diff gets confused by moving two functions earlier in the file.
(Thanks for starting this, Randy ... these two patches should be merged
before RC4 ships.)
- Dave
The usbnet infrastructure must not reference MII symbols unless they're
provided in the kernel being built. This extends also to the ethtool
hooks that reference those symbols.
Signed-off-by: David Brownell [EMAIL PROTECTED]
Index: g26/drivers/usb/net/usbnet.c
===
--- g26.orig/drivers/usb/net/usbnet.c 2006-10-24 18:29:28.0 -0700
+++ g26/drivers/usb/net/usbnet.c2006-10-25 19:07:16.0 -0700
@@ -669,6 +669,9 @@ done:
* they'll probably want to use this base set.
*/
+#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE)
+#define HAVE_MII
+
int usbnet_get_settings (struct net_device *net, struct ethtool_cmd *cmd)
{
struct usbnet *dev = netdev_priv(net);
@@ -699,20 +702,6 @@ int usbnet_set_settings (struct net_devi
}
EXPORT_SYMBOL_GPL(usbnet_set_settings);
-
-void usbnet_get_drvinfo (struct net_device *net, struct ethtool_drvinfo *info)
-{
- struct usbnet *dev = netdev_priv(net);
-
- /* REVISIT don't always return usbnet */
- strncpy (info-driver, driver_name, sizeof info-driver);
- strncpy (info-version, DRIVER_VERSION, sizeof info-version);
- strncpy (info-fw_version, dev-driver_info-description,
- sizeof info-fw_version);
- usb_make_path (dev-udev, info-bus_info, sizeof info-bus_info);
-}
-EXPORT_SYMBOL_GPL(usbnet_get_drvinfo);
-
u32 usbnet_get_link (struct net_device *net)
{
struct usbnet *dev = netdev_priv(net);
@@ -730,40 +719,57 @@ u32 usbnet_get_link (struct net_device *
}
EXPORT_SYMBOL_GPL(usbnet_get_link);
-u32 usbnet_get_msglevel (struct net_device *net)
+int usbnet_nway_reset(struct net_device *net)
{
struct usbnet *dev = netdev_priv(net);
- return dev-msg_enable;
+ if (!dev-mii.mdio_write)
+ return -EOPNOTSUPP;
+
+ return mii_nway_restart(dev-mii);
}
-EXPORT_SYMBOL_GPL(usbnet_get_msglevel);
+EXPORT_SYMBOL_GPL(usbnet_nway_reset);
-void usbnet_set_msglevel (struct net_device *net, u32 level)
+#endif /* HAVE_MII */
+
+void usbnet_get_drvinfo (struct net_device *net, struct ethtool_drvinfo *info)
{
struct usbnet *dev = netdev_priv(net);
- dev-msg_enable = level;
+ /* REVISIT don't always return usbnet */
+ strncpy (info-driver, driver_name, sizeof info-driver);
+ strncpy (info-version, DRIVER_VERSION, sizeof info-version);
+ strncpy (info-fw_version, dev-driver_info-description,
+ sizeof info-fw_version);
+ usb_make_path (dev-udev, info-bus_info, sizeof info-bus_info);
}
-EXPORT_SYMBOL_GPL(usbnet_set_msglevel);
+EXPORT_SYMBOL_GPL(usbnet_get_drvinfo);
-int usbnet_nway_reset(struct net_device *net)
+u32 usbnet_get_msglevel (struct net_device *net)
{
struct usbnet *dev = netdev_priv(net);
- if (!dev-mii.mdio_write)
- return -EOPNOTSUPP;
+ return dev-msg_enable;
+}
+EXPORT_SYMBOL_GPL(usbnet_get_msglevel);
- return mii_nway_restart(dev-mii);
+void usbnet_set_msglevel (struct net_device *net, u32 level)
+{
+ struct usbnet *dev = netdev_priv(net);
+
+ dev-msg_enable = level;
}
-EXPORT_SYMBOL_GPL(usbnet_nway_reset);
+EXPORT_SYMBOL_GPL(usbnet_set_msglevel);
/* drivers may override default ethtool_ops in their bind() routine */
static struct ethtool_ops usbnet_ethtool_ops = {
+#ifdef HAVE_MII
.get_settings = usbnet_get_settings,
.set_settings = usbnet_set_settings,
- .get_drvinfo= usbnet_get_drvinfo,
.get_link = usbnet_get_link,
.nway_reset = usbnet_nway_reset,
+#endif
+ .get_drvinfo= usbnet_get_drvinfo,
.get_msglevel = usbnet_get_msglevel,
.set_msglevel = usbnet_set_msglevel,
};
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Wed, Oct 25, 2006 at 08:37:04PM -0700, Simon Barber wrote: Doing this will slow down the qdisc - it does already run an external classifier first if you install one. On typical laptops performance is not a problem, but one common usage does have problems. The performance of a wireless home gateway based on a simple linux kernel configuration (NAT, iptables, bridging) is significantly slower than a VxWorks based one. With the arrival of 802.11n improving the performance of the stack is very important. The VxWorks solution may be less flexible in terms of what it can do, but it will allow the full 802.11n bandwidth to be achieved on slower embedded CPUs than Linux does. How to improve the linux kernel networking to improve it's efficiency here is a hard problem. First do it right, then tune performance. If you aren't doing it right, then who cares about VxWorks. We also need 802.11 to register as a real protocol, rather than faking ethernet. David Miller did an example stub: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/davem-p80211.tar.bz2 Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
Re: registering as a real protocol - yes this I have been going on about for a while. This needs a few changes in how things work: 1. Register as a real protocol. 2. Change drivers to use netif_rx to receive frames (will also be more efficient) I would also like to see: Drivers to use register_netdev - not special ieee80211 register to register themselves Drivers to use a normal hard_start_xmit function - need to move 802.11 pre xmit frame processing into the qdisc dequeue function Get rid of gunky beacon multicast buffered frame handling - make them into normal queues like everything else (so same hard_start_xmit can be used). Simon -Original Message- From: Jeff Garzik [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 25, 2006 10:04 PM To: Simon Barber Cc: Patrick McHardy; David Kimdon; netdev@vger.kernel.org; John W. Linville; Jiri Benc Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc On Wed, Oct 25, 2006 at 08:37:04PM -0700, Simon Barber wrote: Doing this will slow down the qdisc - it does already run an external classifier first if you install one. On typical laptops performance is not a problem, but one common usage does have problems. The performance of a wireless home gateway based on a simple linux kernel configuration (NAT, iptables, bridging) is significantly slower than a VxWorks based one. With the arrival of 802.11n improving the performance of the stack is very important. The VxWorks solution may be less flexible in terms of what it can do, but it will allow the full 802.11n bandwidth to be achieved on slower embedded CPUs than Linux does. How to improve the linux kernel networking to improve it's efficiency here is a hard problem. First do it right, then tune performance. If you aren't doing it right, then who cares about VxWorks. We also need 802.11 to register as a real protocol, rather than faking ethernet. David Miller did an example stub: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/dave m-p80211.tar.bz2 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: [RFC] tcp: setsockopt congestion control autoload
On Wed, Oct 25, 2006 at 11:08:43AM -0700, Stephen Hemminger ([EMAIL PROTECTED]) wrote: If user asks for a congestion control type with setsockopt() then it may be available as a module not included in the kernel already. It should be autoloaded if needed. This is done already when the default selection is change with sysctl, but not when application requests via sysctl. Only reservation is are there any bad security implications from this? What if system is badly configured, so it is possible to load malicious module by kernel? -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB
David Brownell wrote: On Wednesday 25 October 2006 4:59 pm, Randy Dunlap wrote: On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote: The other parts are right, this isn't. Instead, usbnet.c should #ifdef the relevant ethtool hooks according to CONFIG_MII ... since it's completely legit to use usbnet with peripherals that don't need MII. Ugh. OK. How's this? (2 patches) Looks about right, but ... However, the MII config symbol should not be in the 10/100 Ethernet menu, so that other drivers can use (enable) it or so that users can enable it without needing to enable 10/100 Ethernet. ... MII should still depend on ETHERNET, right? Just not limited to 10/100 Ethernet. There is no such config symbol. NET_ETHERNET means 10/100 ethernet. Gigabit ethernet doesn't use the ETHERNET symbol (and doesn't use this flavor of MII IIRC). And all of this config space is surrounded by: # All the following symbols are dependent on NETDEVICES - do not repeat # that for each of the symbols. if NETDEVICES so it is actually config MII depends on NETDEVICES What do you suggest? --- linux-2619-rc3-pv.orig/drivers/net/Kconfig +++ linux-2619-rc3-pv/drivers/net/Kconfig @@ -145,6 +145,13 @@ config NET_SB1000 source drivers/net/arcnet/Kconfig +config MII + tristate Generic Media Independent Interface device support + help + Most ethernet controllers have MII transceiver either as an external + or internal device. It is safe to say Y or M here even if your + ethernet card lacks MII. + source drivers/net/phy/Kconfig # @@ -180,14 +187,6 @@ config NET_ETHERNET kernel: saying N will just cause the configurator to skip all the questions about Ethernet network cards. If unsure, say N. -config MII - tristate Generic Media Independent Interface device support - depends on NET_ETHERNET - help - Most ethernet controllers have MII transceiver either as an external - or internal device. It is safe to say Y or M here even if your - ethernet card lack MII. - source drivers/net/arm/Kconfig config MACE -- ~Randy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB
On Wednesday 25 October 2006 10:05 pm, Randy.Dunlap wrote: ... MII should still depend on ETHERNET, right? Just not limited to 10/100 Ethernet. There is no such config symbol. NET_ETHERNET means 10/100 ethernet. Gigabit ethernet doesn't use the ETHERNET symbol (and doesn't use this flavor of MII IIRC). Ah, you're right -- sorry. Only Kconfig and net/ipv4/arp.c even look for that config symbol. - Dave - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
