Re: [PATCH] sungem: PHY updates & pause fixes
> The one with only asym. support is a big Cisco Catalyst 3350 (well.. big > but not that many ports :-) Ok, I got in the config of the switch with somebody who knows how to speak ciscong, and it seems that it defaults to flow control "desired" for send and "off" for receive on all ports, which means it will indeed only advertise support for asymetrical flow control. We've changed the setting for the port on which my sungem g5 is connected to "desired" on both send and receive, and it now advertises flow control on both, and sungem does pick it up properly. So it's indeed the default setting of those cisco switches that seem to not quite match what drivers like sungem or tg3 like. Ben. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
> ..same problem with 2.6.20-rc3. Last worked with > 2.6.19-rc6-git12, so it was 2.6.19 where it failed. > Attaching both case1 normal, case2 acpi=noirq. With acpi=noirq ethernet > doesn't get configured, route -n says it's an Unsupported operation, > ifconfig only shows for localhost, ifconfig eth0 192.168.10.5 also > complains of a config error. It seems that the "acpi=noirq" (and probably also the acpi=off) case is simply an additional broken case, not a success case to compare to. The thing we really want to compare is dmesg and /proc/interrupts from 2.6.19-rc6-git12, and the broken current release. Perhaps you can put that info in the bug report when you file it. thanks, -Len - 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
[no subject]
subscribe netdev - 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] sungem: PHY updates & pause fixes
On Tue, 2007-01-02 at 21:26 -0800, David Miller wrote: > From: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > Date: Wed, 03 Jan 2007 16:20:14 +1100 > > > Now, I cross-over with a TG3 and I get: > > > > - I advertise 0x5e1 (hopefully same value) > > - I read in LPA 0xc5e1 from the TG3 > > (and that other register tells me Rx and Tx pause can be enabled). > > Does flow control get enabled with the TG3 on these > switches? Just curious. On the quad G5 which has tg3, I get "Flow control is on for TX and on for RX". Let me double check if I'm on the same switch... Heh ! It's not :-) If I switch the cables, then pause is enabled on the sungem box and disabled (both Tx and Rx) on tg3, so at least the behaviour is consistent and follow the switches. Let me check the switch models... The one with only asym. support is a big Cisco Catalyst 3350 (well.. big but not that many ports :-) The one with "classic" pause support is a tiny Netgear GS116 It's possible that the cisco is just misconfigured though, I'll have to ask Keith when he's around tomorrow to take a peek at the mgmnt interface. > > > You should try to use flow control, even slower than 1000Mbit links. > > > > Sorry, not sure I parse ;-) You mean allowing pause on 10 and 100 as > > well ? I sure can, it's easy to fix. > > That's correct. On it's way. Ben. - 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] sungem: PHY updates & pause fixes (#2)
This patch adds support for a few more PHYs used by Apple and fixes
advertising and detecting of Pause (we were missing setting the bit in
MII_ADVERTISE and weren't testing in LPA for all PHYs).
Note that I currently only advertise pause, not asymetric pause. I don't
know for sure the details there, I suppose I should read a bit more
802.3 references, and I don't now what sungem is capable of, but I
noticed the PCS code (originated from you) does the same.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
(Applies on top of Eric's locking patch)
This version advertise pause support for all speeds. Note that I think
pause support was never broken for PCS, only for MII.
Index: linux-work/drivers/net/sungem_phy.c
===
--- linux-work.orig/drivers/net/sungem_phy.c2007-01-03 12:04:12.0
+1100
+++ linux-work/drivers/net/sungem_phy.c 2007-01-03 16:28:55.0 +1100
@@ -3,10 +3,9 @@
*
* This file could be shared with other drivers.
*
- * (c) 2002, Benjamin Herrenscmidt ([EMAIL PROTECTED])
+ * (c) 2002-2007, Benjamin Herrenscmidt ([EMAIL PROTECTED])
*
* TODO:
- * - Implement WOL
* - Add support for PHYs that provide an IRQ line
* - Eventually moved the entire polling state machine in
*there (out of the eth driver), so that it can easily be
@@ -152,6 +151,44 @@ static int bcm5221_suspend(struct mii_ph
return 0;
}
+static int bcm5241_init(struct mii_phy* phy)
+{
+ u16 data;
+
+ data = phy_read(phy, MII_BCM5221_TEST);
+ phy_write(phy, MII_BCM5221_TEST,
+ data | MII_BCM5221_TEST_ENABLE_SHADOWS);
+
+ data = phy_read(phy, MII_BCM5221_SHDOW_AUX_STAT2);
+ phy_write(phy, MII_BCM5221_SHDOW_AUX_STAT2,
+ data | MII_BCM5221_SHDOW_AUX_STAT2_APD);
+
+ data = phy_read(phy, MII_BCM5221_SHDOW_AUX_MODE4);
+ phy_write(phy, MII_BCM5221_SHDOW_AUX_MODE4,
+ data & ~MII_BCM5241_SHDOW_AUX_MODE4_STANDBYPWR);
+
+ data = phy_read(phy, MII_BCM5221_TEST);
+ phy_write(phy, MII_BCM5221_TEST,
+ data & ~MII_BCM5221_TEST_ENABLE_SHADOWS);
+
+ return 0;
+}
+
+static int bcm5241_suspend(struct mii_phy* phy)
+{
+ u16 data;
+
+ data = phy_read(phy, MII_BCM5221_TEST);
+ phy_write(phy, MII_BCM5221_TEST,
+ data | MII_BCM5221_TEST_ENABLE_SHADOWS);
+
+ data = phy_read(phy, MII_BCM5221_SHDOW_AUX_MODE4);
+ phy_write(phy, MII_BCM5221_SHDOW_AUX_MODE4,
+ data | MII_BCM5241_SHDOW_AUX_MODE4_STANDBYPWR);
+
+ return 0;
+}
+
static int bcm5400_init(struct mii_phy* phy)
{
u16 data;
@@ -373,6 +410,10 @@ static int bcm54xx_setup_aneg(struct mii
adv |= ADVERTISE_100HALF;
if (advertise & ADVERTISED_100baseT_Full)
adv |= ADVERTISE_100FULL;
+ if (advertise & ADVERTISED_Pause)
+ adv |= ADVERTISE_PAUSE_CAP;
+ if (advertise & ADVERTISED_Asym_Pause)
+ adv |= ADVERTISE_PAUSE_ASYM;
phy_write(phy, MII_ADVERTISE, adv);
/* Setup 1000BT advertise */
@@ -436,12 +477,15 @@ static int bcm54xx_read_link(struct mii_
val = phy_read(phy, MII_BCM5400_AUXSTATUS);
link_mode = ((val & MII_BCM5400_AUXSTATUS_LINKMODE_MASK) >>
MII_BCM5400_AUXSTATUS_LINKMODE_SHIFT);
- phy->duplex = phy_BCM5400_link_table[link_mode][0] ?
DUPLEX_FULL : DUPLEX_HALF;
+ phy->duplex = phy_BCM5400_link_table[link_mode][0] ?
+ DUPLEX_FULL : DUPLEX_HALF;
phy->speed = phy_BCM5400_link_table[link_mode][2] ?
SPEED_1000 :
- (phy_BCM5400_link_table[link_mode][1] ?
SPEED_100 : SPEED_10);
+ (phy_BCM5400_link_table[link_mode][1] ?
+SPEED_100 : SPEED_10);
val = phy_read(phy, MII_LPA);
- phy->pause = ((val & LPA_PAUSE) != 0);
+ phy->pause = (phy->duplex == DUPLEX_FULL) &&
+ ((val & LPA_PAUSE) != 0);
}
/* On non-aneg, we assume what we put in BMCR is the speed,
* though magic-aneg shouldn't prevent this case from occurring
@@ -450,6 +494,28 @@ static int bcm54xx_read_link(struct mii_
return 0;
}
+static int marvell88e_init(struct mii_phy* phy)
+{
+ u16 rev;
+
+ /* magic init sequence for rev 0 */
+ rev = phy_read(phy, MII_PHYSID2) & 0x000f;
+ if (rev == 0) {
+ phy_write(phy, 0x1d, 0x000a);
+ phy_write(phy, 0x1e, 0x0821);
+
+ phy_write(phy, 0x1d, 0x0006);
+ phy_write(phy, 0x1e, 0x8600);
+
+ phy_write(phy, 0x1d, 0x000b);
+ phy_write(phy, 0x1e, 0x0100);
+
+ phy_write(phy, 0x1d, 0x0004);
+ phy_write(phy, 0x1e, 0x4850);
+ }
+ return 0
Re: [PATCH] sungem: PHY updates & pause fixes
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]> Date: Wed, 03 Jan 2007 16:20:14 +1100 > Now, I cross-over with a TG3 and I get: > > - I advertise 0x5e1 (hopefully same value) > - I read in LPA 0xc5e1 from the TG3 > (and that other register tells me Rx and Tx pause can be enabled). Does flow control get enabled with the TG3 on these switches? Just curious. > > You should try to use flow control, even slower than 1000Mbit links. > > Sorry, not sure I parse ;-) You mean allowing pause on 10 and 100 as > well ? I sure can, it's easy to fix. That's correct. > > That's the only problem I can see, would you mind fixing that and > > I'll put your change into my net-2.6 tree and perhaps play around > > with PAUSE on my switches here? > > Sure will do. Thanks a lot. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sungem: PHY updates & pause fixes
> Thanks for finding these bugs, although that's really strange pause > behavior you are seeing on your switches. > > By default, we advertise PAUSE but not ASYM PAUSE in the tg3 driver, > and I get flow control on every switch I have here. Yeah, that's strange. I still have the debug values at hand: - I advertise 0x5e1 - I read in LPA 0xc9e1 from the switch (and my bcm PHY tells me Rx and Tx pause disabled in a separate register) Now, I cross-over with a TG3 and I get: - I advertise 0x5e1 (hopefully same value) - I read in LPA 0xc5e1 from the TG3 (and that other register tells me Rx and Tx pause can be enabled). > You should try to use flow control, even slower than 1000Mbit links. Sorry, not sure I parse ;-) You mean allowing pause on 10 and 100 as well ? I sure can, it's easy to fix. > That's the only problem I can see, would you mind fixing that and > I'll put your change into my net-2.6 tree and perhaps play around > with PAUSE on my switches here? Sure will do. Ben. - 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] sungem: PHY updates & pause fixes
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]> Date: Wed, 03 Jan 2007 15:58:05 +1100 > This patch adds support for a few more PHYs used by Apple and fixes > advertising and detecting of Pause (we were missing setting the bit in > MII_ADVERTISE and weren't testing in LPA for all PHYs). I only do it for > gigabit capable PHYs for now. > > Note that I currently only advertise pause, not asymetric pause. I don't > know for sure the details there, I suppose I should read a bit more > 802.3 references, and I don't now what sungem is capable of, but I > noticed the PCS code (originated from you) does the same. > > Unfortunately, whatever switches we have here also seem to only support > asym. pause, so while I did a quick test to verify that pause is > properly enabled on a cross-over cable to another machine, I still get > occasional RX fifo overflows due to pause support lacking on our > internal network. > > So let me know if asym. pause is something we can support with sungem. > In which case, it shouldn't be very hard to add in a subsequent patch. > > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> Thanks for finding these bugs, although that's really strange pause behavior you are seeing on your switches. By default, we advertise PAUSE but not ASYM PAUSE in the tg3 driver, and I get flow control on every switch I have here. You should try to use flow control, even slower than 1000Mbit links. That's the only problem I can see, would you mind fixing that and I'll put your change into my net-2.6 tree and perhaps play around with PAUSE on my switches here? Thanks! - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] sungem: PHY updates & pause fixes
This patch adds support for a few more PHYs used by Apple and fixes
advertising and detecting of Pause (we were missing setting the bit in
MII_ADVERTISE and weren't testing in LPA for all PHYs). I only do it for
gigabit capable PHYs for now.
Note that I currently only advertise pause, not asymetric pause. I don't
know for sure the details there, I suppose I should read a bit more
802.3 references, and I don't now what sungem is capable of, but I
noticed the PCS code (originated from you) does the same.
Unfortunately, whatever switches we have here also seem to only support
asym. pause, so while I did a quick test to verify that pause is
properly enabled on a cross-over cable to another machine, I still get
occasional RX fifo overflows due to pause support lacking on our
internal network.
So let me know if asym. pause is something we can support with sungem.
In which case, it shouldn't be very hard to add in a subsequent patch.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
(Applies on top of Eric's locking patch)
Index: linux-work/drivers/net/sungem_phy.c
===
--- linux-work.orig/drivers/net/sungem_phy.c2007-01-03 12:04:12.0
+1100
+++ linux-work/drivers/net/sungem_phy.c 2007-01-03 15:51:39.0 +1100
@@ -3,10 +3,9 @@
*
* This file could be shared with other drivers.
*
- * (c) 2002, Benjamin Herrenscmidt ([EMAIL PROTECTED])
+ * (c) 2002-2007, Benjamin Herrenscmidt ([EMAIL PROTECTED])
*
* TODO:
- * - Implement WOL
* - Add support for PHYs that provide an IRQ line
* - Eventually moved the entire polling state machine in
*there (out of the eth driver), so that it can easily be
@@ -15,7 +14,7 @@
*to read the link status. Figure out why and if it makes
*sense to do the same (magic aneg ?)
* - Apple has some additional power management code for some
- *Broadcom PHYs that they "hide" from the OpenSource version
+ *Broadcom PHYs that they "hide" from the OpenSource version
*of darwin, still need to reverse engineer that
*/
@@ -152,6 +151,44 @@ static int bcm5221_suspend(struct mii_ph
return 0;
}
+static int bcm5241_init(struct mii_phy* phy)
+{
+ u16 data;
+
+ data = phy_read(phy, MII_BCM5221_TEST);
+ phy_write(phy, MII_BCM5221_TEST,
+ data | MII_BCM5221_TEST_ENABLE_SHADOWS);
+
+ data = phy_read(phy, MII_BCM5221_SHDOW_AUX_STAT2);
+ phy_write(phy, MII_BCM5221_SHDOW_AUX_STAT2,
+ data | MII_BCM5221_SHDOW_AUX_STAT2_APD);
+
+ data = phy_read(phy, MII_BCM5221_SHDOW_AUX_MODE4);
+ phy_write(phy, MII_BCM5221_SHDOW_AUX_MODE4,
+ data & ~MII_BCM5241_SHDOW_AUX_MODE4_STANDBYPWR);
+
+ data = phy_read(phy, MII_BCM5221_TEST);
+ phy_write(phy, MII_BCM5221_TEST,
+ data & ~MII_BCM5221_TEST_ENABLE_SHADOWS);
+
+ return 0;
+}
+
+static int bcm5241_suspend(struct mii_phy* phy)
+{
+ u16 data;
+
+ data = phy_read(phy, MII_BCM5221_TEST);
+ phy_write(phy, MII_BCM5221_TEST,
+ data | MII_BCM5221_TEST_ENABLE_SHADOWS);
+
+ data = phy_read(phy, MII_BCM5221_SHDOW_AUX_MODE4);
+ phy_write(phy, MII_BCM5221_SHDOW_AUX_MODE4,
+ data | MII_BCM5241_SHDOW_AUX_MODE4_STANDBYPWR);
+
+ return 0;
+}
+
static int bcm5400_init(struct mii_phy* phy)
{
u16 data;
@@ -373,6 +410,10 @@ static int bcm54xx_setup_aneg(struct mii
adv |= ADVERTISE_100HALF;
if (advertise & ADVERTISED_100baseT_Full)
adv |= ADVERTISE_100FULL;
+ if (advertise & ADVERTISED_Pause)
+ adv |= ADVERTISE_PAUSE_CAP;
+ if (advertise & ADVERTISED_Asym_Pause)
+ adv |= ADVERTISE_PAUSE_ASYM;
phy_write(phy, MII_ADVERTISE, adv);
/* Setup 1000BT advertise */
@@ -441,7 +482,7 @@ static int bcm54xx_read_link(struct mii_
SPEED_1000 :
(phy_BCM5400_link_table[link_mode][1] ?
SPEED_100 : SPEED_10);
val = phy_read(phy, MII_LPA);
- phy->pause = ((val & LPA_PAUSE) != 0);
+ phy->pause = (phy->duplex == DUPLEX_FULL) && ((val & LPA_PAUSE)
!= 0);
}
/* On non-aneg, we assume what we put in BMCR is the speed,
* though magic-aneg shouldn't prevent this case from occurring
@@ -450,6 +491,28 @@ static int bcm54xx_read_link(struct mii_
return 0;
}
+static int marvell88e_init(struct mii_phy* phy)
+{
+ u16 rev;
+
+ /* magic init sequence for rev 0 */
+ rev = phy_read(phy, MII_PHYSID2) & 0x000f;
+ if (rev == 0) {
+ phy_write(phy, 0x1d, 0x000a);
+ phy_write(phy, 0x1e, 0x0821);
+
+ phy_write(phy, 0x1d, 0x0006);
+ phy_write(phy, 0x1e, 0x8600);
+
+ phy_write(phy, 0x1d, 0x000b);
+ phy_write(phy, 0x1e, 0x0100);
+
+ phy_wr
Please pull 'upstream' branch of wireless-2.6
The following changes since commit fe5f8e2a1c5c040209c598a28e19c55f30e1040d:
Zhu Yi (1):
ipw2100: Fix dropping fragmented small packet problem
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream
Daniel Drake (5):
zd1211rw: Generic HMAC initialization
zd1211rw: 2 new ZD1211B device ID's
zd1211rw: Consistency for address space constants
zd1211rw: Remove addressing abstraction
zd1211rw: Add ID for Linksys WUSBF54G
John W. Linville (1):
softmac: avoid assert in ieee80211softmac_wx_get_rate
Kai Engert (1):
prism54: add ethtool -i interface
Larry Finger (1):
bcm43xx: Interrogate hardware-enable switch and update LEDs
Michael Buesch (1):
Update Prism54 MAINTAINERS entry
MAINTAINERS |2 +-
drivers/net/wireless/bcm43xx/bcm43xx.h|7 +-
drivers/net/wireless/bcm43xx/bcm43xx_leds.c | 11 +-
drivers/net/wireless/bcm43xx/bcm43xx_main.c | 36 --
drivers/net/wireless/bcm43xx/bcm43xx_radio.c |2 +
drivers/net/wireless/bcm43xx/bcm43xx_radio.h | 16 +++
drivers/net/wireless/prism54/islpci_dev.c | 13 ++
drivers/net/wireless/prism54/islpci_dev.h |4 +
drivers/net/wireless/prism54/islpci_hotplug.c |3 -
drivers/net/wireless/zd1211rw/zd_chip.c | 126 ++--
drivers/net/wireless/zd1211rw/zd_chip.h | 158 ++---
drivers/net/wireless/zd1211rw/zd_def.h|2 +
drivers/net/wireless/zd1211rw/zd_ieee80211.h |1 -
drivers/net/wireless/zd1211rw/zd_rf.h |2 -
drivers/net/wireless/zd1211rw/zd_types.h | 71 ---
drivers/net/wireless/zd1211rw/zd_usb.c| 127 ++--
drivers/net/wireless/zd1211rw/zd_usb.h|6 +-
net/ieee80211/softmac/ieee80211softmac_wx.c |6 +
18 files changed, 253 insertions(+), 340 deletions(-)
delete mode 100644 drivers/net/wireless/zd1211rw/zd_types.h
diff --git a/MAINTAINERS b/MAINTAINERS
index d5a97d3..edb4c39 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2606,7 +2606,7 @@ S:Supported
PRISM54 WIRELESS DRIVER
P: Prism54 Development Team
-M: [EMAIL PROTECTED]
+M: [EMAIL PROTECTED]
L: netdev@vger.kernel.org
W: http://prism54.org
S: Maintained
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx.h
b/drivers/net/wireless/bcm43xx/bcm43xx.h
index 8286678..3a064de 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx.h
+++ b/drivers/net/wireless/bcm43xx/bcm43xx.h
@@ -352,6 +352,10 @@
#define BCM43xx_UCODEFLAG_UNKPACTRL0x0040
#define BCM43xx_UCODEFLAG_JAPAN0x0080
+/* Hardware Radio Enable masks */
+#define BCM43xx_MMIO_RADIO_HWENABLED_HI_MASK (1 << 16)
+#define BCM43xx_MMIO_RADIO_HWENABLED_LO_MASK (1 << 4)
+
/* Generic-Interrupt reasons. */
#define BCM43xx_IRQ_READY (1 << 0)
#define BCM43xx_IRQ_BEACON (1 << 1)
@@ -758,7 +762,8 @@ struct bcm43xx_private {
bad_frames_preempt:1, /* Use "Bad Frames Preemption" (default
off) */
reg124_set_0x4:1, /* Some variable to keep track of IRQ
stuff. */
short_preamble:1, /* TRUE, if short preamble is enabled.
*/
- firmware_norelease:1; /* Do not release the firmware. Used on
suspend. */
+ firmware_norelease:1, /* Do not release the firmware. Used on
suspend. */
+ radio_hw_enable:1; /* TRUE if radio is hardware enabled */
struct bcm43xx_stats stats;
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_leds.c
b/drivers/net/wireless/bcm43xx/bcm43xx_leds.c
index 7d383a2..8f198be 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_leds.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_leds.c
@@ -26,6 +26,7 @@
*/
#include "bcm43xx_leds.h"
+#include "bcm43xx_radio.h"
#include "bcm43xx.h"
#include
@@ -108,6 +109,7 @@ static void bcm43xx_led_init_hardcoded(struct
bcm43xx_private *bcm,
switch (led_index) {
case 0:
led->behaviour = BCM43xx_LED_ACTIVITY;
+ led->activelow = 1;
if (bcm->board_vendor == PCI_VENDOR_ID_COMPAQ)
led->behaviour = BCM43xx_LED_RADIO_ALL;
break;
@@ -199,20 +201,21 @@ void bcm43xx_leds_update(struct bcm43xx_private *bcm, int
activity)
turn_on = activity;
break;
case BCM43xx_LED_RADIO_ALL:
- turn_on = radio->enabled;
+ turn_on = radio->enabled &&
bcm43xx_is_hw_radio_enabled(bcm);
break;
case BCM43xx_LED_RADIO_A:
case BCM43xx_LED_BCM4303_2:
- turn_on = (radio->enabled && phy->type ==
BCM43xx_PHYTYPE_A);
+ turn_on = (radio->enabled &&
bcm43xx_is_hw_radio_enabled(bcm) &&
+ phy->type ==
Please pull 'upstream-fixes' branch of wireless-2.6
The following changes since commit 669df1b478803f49a356528d290af7bf442eb3be:
Linus Torvalds (1):
Linux 2.6.20-rc3
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream-fixes
Zhu Yi (2):
ieee80211: WLAN_GET_SEQ_SEQ fix (select correct region)
ipw2100: Fix dropping fragmented small packet problem
drivers/net/wireless/ipw2100.c |2 +-
include/net/ieee80211.h|2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ipw2100.c b/drivers/net/wireless/ipw2100.c
index 0e94fbb..b85857a 100644
--- a/drivers/net/wireless/ipw2100.c
+++ b/drivers/net/wireless/ipw2100.c
@@ -2664,7 +2664,7 @@ static void __ipw2100_rx_process(struct ipw2100_priv
*priv)
break;
}
#endif
- if (stats.len < sizeof(u->rx_data.header))
+ if (stats.len < sizeof(struct ieee80211_hdr_3addr))
break;
switch (WLAN_FC_GET_TYPE(u->rx_data.header.frame_ctl)) {
case IEEE80211_FTYPE_MGMT:
diff --git a/include/net/ieee80211.h b/include/net/ieee80211.h
index e6af381..e02d85f 100644
--- a/include/net/ieee80211.h
+++ b/include/net/ieee80211.h
@@ -218,7 +218,7 @@ struct ieee80211_snap_hdr {
#define WLAN_FC_GET_STYPE(fc) ((fc) & IEEE80211_FCTL_STYPE)
#define WLAN_GET_SEQ_FRAG(seq) ((seq) & IEEE80211_SCTL_FRAG)
-#define WLAN_GET_SEQ_SEQ(seq) ((seq) & IEEE80211_SCTL_SEQ)
+#define WLAN_GET_SEQ_SEQ(seq) (((seq) & IEEE80211_SCTL_SEQ) >> 4)
/* Authentication algorithms */
#define WLAN_AUTH_OPEN 0
--
John W. Linville
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please pull 'upstream' branch of wireless-2.6
On Wed, Dec 27, 2006 at 07:10:57PM -0500, John W. Linville wrote: > On Tue, Dec 26, 2006 at 04:39:38PM -0500, Jeff Garzik wrote: > > John W. Linville wrote: > > >The following changes since commit > > >0c234ae655a45ac3ee53a25b2e56e9bb6c27d71d: > > > Ulrich Kunitz (1): > > >ieee80211softmac: Fix mutex_lock at exit of > > >ieee80211_softmac_get_genie > > > > > >are found in the git repository at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git > > > upstream > > > > > >Roy Marples (1): > > > prism54: set carrier flags correctly > > > > Why is this not #upstream-fixes material? What's the impact? > > Just being cautious, really. I have no objection if you want to pull > it as a fix. After further review... Jeff, it looks like you have not pulled this one so far. Based on the commentary from Roger While [1], lets hold-off on this one. Roy, please consider refactoring your patch based on Roger's comments. Thanks, John [1] http://marc.10east.com/?l=linux-netdev&m=116740017623597&w=2 -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] the scheduled eepro100 removal
02.01.2007 22:57, Adrian Bunk wrote/a écrit: This patch contains the scheduled removal of the eepro100 driver. Hi, I've been using e100 for years with no problem, however more by curiosity than necessity I'd like to know how will be handled the devices which are (supposedly) supported by eepro100 and not by e100? According to "modinfo eepro100" and "modinfo e100" those devices IDs are only matched by eepro100: +alias: pci:v8086d1035sv +alias: pci:v8086d1036sv +alias: pci:v8086d1037sv +alias: pci:v8086d1227sv +alias: pci:v8086d5200sv +alias: pci:v8086d5201sv Are they matched by some joker rule that I haven't noticed in e100, or is support for them really going to disappear? See you, Eric - 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: BUG: soft lockup detected on CPU#0! (2.6.18.2 plus hacks)
David Stevens wrote: I've looked at this a little too -- it'd be nice to know who holds the write lock. I see ip_mc_destroy_dev() is bouncing through the lock for each multicast address, though it starts at the beginning of the list each time. I don't see a problem with it, but it'd be simpler if it acquired the write lock once, grabbed and nulled the list, released the lock and then called igmp_group_dropped() & ip_ma_put() on each address from the local list copy. Are you destroying/creating interfaces or doing a lot of multicasting at the time? How many group memberships do you have? Lots and lots of interfaces were being created...at least 200 mac-vlans (out-of tree patch somewhat similar to 802.1q vlans.) The avahi-daemon process was running, and it appears to be adding a multicast to each interface. It was spewing failure messages in /var/log/messages, probably because it can't handle so many interfaces. Other than that, there is no (known) multicast traffic being generated. This bug was reported to me by a user in Australia, and we have not yet attempted to recreate this locally, so I am not certain exactly what it takes to trigger this bug. Thanks, Ben +-DLS -- 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: selinux networking: sleeping functin called from invalid context in 2.6.20-rc[12]
From: Paul Moore <[EMAIL PROTECTED]> Date: Tue, 2 Jan 2007 16:25:24 -0500 > I'm sorry I just saw this mail (mail not sent directly to me get > shuffled off to a folder). I agree with your patch, I think > dropping and then re-taking the RCU lock is the best way to go, > although I'm curious to see what others have to say. I think this is fine too. - 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] net/core/flow.c: compare data with memcmp
From: "Daniel_Marjamäki" <[EMAIL PROTECTED]> Date: Mon, 1 Jan 2007 10:16:02 +0100 > I have done a little testing on my own. My results is that memcpy is > many times faster even with aligned data. Your test program doesn't make any measurements, from where did you get these "results"? Also, your test program is broken because in the memcmp() case GCC totally optimizes away the call to memcmp() because it can see the comparison data at compile time and therefore it computes the memcmp() result at compile time. There are no memcmp() calls made at all by your program. You should look at the assembler code emitted by a test program that is measuring performance, in detail, to make sure the test program really is doing what you think it is. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: soft lockup detected on CPU#0! (2.6.18.2 plus hacks)
I've looked at this a little too -- it'd be nice to know who holds the write lock. I see ip_mc_destroy_dev() is bouncing through the lock for each multicast address, though it starts at the beginning of the list each time. I don't see a problem with it, but it'd be simpler if it acquired the write lock once, grabbed and nulled the list, released the lock and then called igmp_group_dropped() & ip_ma_put() on each address from the local list copy. Are you destroying/creating interfaces or doing a lot of multicasting at the time? How many group memberships do you have? +-DLS - 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] net: af_netlink module_put cleanup
From: Mariusz Kozlowski <[EMAIL PROTECTED]> Date: Tue, 2 Jan 2007 13:47:37 +0100 > Hello, > > This patch removes redundant argument check for module_put(). > > Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]> Applied, thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xfrm_user: avoid pointless void ** casts
From: Christoph Hellwig <[EMAIL PROTECTED]> Date: Tue, 2 Jan 2007 15:39:06 +0100 > All ->doit handlers want a struct rtattr **, so pass down the right > type. > > > Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]> This code was just trying to mirror the typing used by struct rtnetlink_link's ->doit() method. But of course you're right in that here the type is always the same. Applied, thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: ifb error path loop fix
From: Mariusz Kozlowski <[EMAIL PROTECTED]>
Date: Tue, 2 Jan 2007 11:49:42 +0100
> Hello David,
>
> > One could argue from a defensive programming perspective that
> > this bug comes from the fact that the ifb_init_one() loop
> > advances state before checking for errors ('i' is advanced before
> > the 'err' check due to the loop construct), and that's why the
> > error recovery code had to be coded specially :-)
>
> Now when I look at it I might be wrong and it is not a bug at all.
> It's just coded in weird way. Anyway isn't there kfree(ifbs) missing
> on error path?
>
> The patch below should clear things a bit (against plain 2.6.20-rc2-mm1).
>
> Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
Ok, I've removed the original patch from my tree.
I'll let this cleanup sit for a while so others can review
it :-)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/6] sky2 driver update (v1.11)
> > > IMHO, it is bad security policy to allow wake on lan to enabled by > > > default. The sky2 driver doesn't do WOL until enabled with ethtool. > > > > While in general I agree with you on the security principle, this seems > > like it might break working setups. > > > > WOL is a partnership between the motherboard and NIC. The motherboard > > must support WOL, or its useless. And since the motherboard must > > support WOL, it normally has an on/off switch in BIOS. > > > > As such, you're overriding the admin's chosen BIOS setting here. > > But there is no way to read the BIOS settings. true. > If BIOS was being smart enough to actually, setup the chip, then I can > look at chip registers on startup and see if it is enabled there. If the BIOS doesn't setup the chip, WOL won't work if you plug in the power cord (instead of just using atx poweroff) and is thus nearly useless. Correct? So I'd propose to read the chip registers and set them to the state they were in on bootup. Kind regards, Gerd - 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: selinux networking: sleeping functin called from invalid context in 2.6.20-rc[12]
On Tuesday, January 2 2007 2:58 am, Adam J. Richter wrote: > I have not yet performed the 21 steps of > linux-2.6.20-rc3/Documentation/SubmitChecklist, which I think is a > great objectives list for future automation or some kind of community > web site. I hope to find time to make progress through that > checklist, but, in the meantime, I think the world may nevertheless be > infinitesmally better off if I post the patch that I'm currently > using that seems to fix the problem, seeing as how rc3 has passed > with no fix incorporated. > > I think the intent of the offending code was to avoid doing > a lock_sock() in a presumably common case where there was no need to > take the lock. So, I have kept the presumably fast test to exit > early. > > When it turns out to be necessary to take lock_sock(), RCU is > unlocked, then lock_sock is taken, the RCU is locked again, and > the test is repeated. Hi Adam, I'm sorry I just saw this mail (mail not sent directly to me get shuffled off to a folder). I agree with your patch, I think dropping and then re-taking the RCU lock is the best way to go, although I'm curious to see what others have to say. The only real comment I have with the patch is that there is some extra whitespace which could probably be removed, but that is more of a style nit than anything substantial. > By the way, in a change not included in this patch, > I also tried consolidating the RCU locking in this file into a macro > IF_NLBL_REQUIRE(sksec, action), where "action" is the code > fragment to be executed with rcu_read_lock() held, although this > required splitting a couple of functions in half. >From your description above I'm not sure I like that approach so much, however, I could be misunderstanding something. Do you have a small example you could send? -- paul moore linux security @ hp - 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: selinux networking: sleeping functin called from invalid context in 2.6.20-rc[12]
On Sunday, December 24 2006 7:25 pm, Andrew Morton wrote: > On Mon, 25 Dec 2006 05:21:24 +0800 > > "Adam J. Richter" <[EMAIL PROTECTED]> wrote: > > Under 2.6.20-rc1 and 2.6.20-rc2, I get the following complaint > > for several network programs running on my system: > > > > [ 156.381868] BUG: sleeping function called from invalid context at > > net/core/sock.c:1523 [ 156.381876] in_atomic():1, irqs_disabled():0 > > [ 156.381881] no locks held by kio_http/9693. > > [ 156.381886] [] show_trace_log_lvl+0x1a/0x2f > > [ 156.381900] [] show_trace+0x12/0x14 > > [ 156.381908] [] dump_stack+0x16/0x18 > > [ 156.381917] [] __might_sleep+0xe5/0xeb > > [ 156.381926] [] lock_sock_nested+0x1d/0xc4 > > [ 156.381937] [] selinux_netlbl_inode_permission+0x5a/0x8e > > [ 156.381946] [] selinux_file_permission+0x96/0x9b > > [ 156.381954] [] vfs_write+0x8d/0x167 > > [ 156.381962] [] sys_write+0x3f/0x63 > > [ 156.381971] [] syscall_call+0x7/0xb > > [ 156.381980] === > > There's a glaring bug in selinux_netlbl_inode_permission() - taking > lock_sock() inside rcu_read_lock(). Sorry for the delay, I'm finally back at a machine where I can look at the code. I've been thinking about Parag Warudkar's and Ingo Molnar's patches as well as what the selinux_netlbl_inode_permission() function actually needs to do; I think the best answer isn't so much to change the socket locking calls, but to restructure the function a bit. Currently the function does the following (in order): 1. do some quick sanity checks (is the inode a socket, etc) 2. rcu_read_lock() 3. check the nlbl_state is set to NLBL_REQUIRE (otherwise return) 4. lock_sock() 5. netlabel magic 6. release_sock() 7. rcu_read_unlock() I propose changing it to the following (in order): 1. do some quick sanity checks (is the inode a socket, etc) 2. rcu_read_lock() 3. check the nlbl_state is set to NLBL_REQUIRE (otherwise return) 4. rcu_read_unlock() 5. lock_sock() 6. rcu_read_lock() 7. verify that nlbl_state is still set to NLBL_REQUIRE (otherwise return) 8. netlabel magic 9. rcu_read_unlock() 10. release_sock() This way we no longer need to worry about any special socket locking. I realize this adds a bit of duplicated work but it is my understanding that RCU lock/unlock operations are *very* fast so the extra RCU lock operations shouldn't be too bad and the extra nlbl_state check should be of minimal cost. However, I'm not the expert here, just a guy learning as he goes so any comments/feedback on the above proposal are welcome. If it turns out this approach has some merit I'll put together a patch and send it out. Once again, sorry for the regression. -- paul moore linux security @ hp - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] net/irda/: proper prototypes
From: Adrian Bunk <[EMAIL PROTECTED]> Date: Tue, 2 Jan 2007 13:45:57 +0100 > On Tue, Jan 02, 2007 at 12:39:53AM -0800, David Miller wrote: > > I don't like it, even if it's "correct", because it is inconsistent > > with what we do in the entire rest of the networking code. > > Good point. > > Is it OK to slowly starting converting them or do you want them to stay? If I saw some value in it I'd say to convert, but I don't so I'd say let's keep them the way they are. - 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] selinux: fix selinux_netlbl_inode_permission() locking
* Andrew Morton <[EMAIL PROTECTED]> wrote: > There's a glaring bug in selinux_netlbl_inode_permission() - taking > lock_sock() inside rcu_read_lock(). Note that the bug is still in -rc3, and is easily triggerable via a default FC6 bootup. It's fixed by the (slightly modified) patch from Parag Warudkar below that i have in the -rt tree. Note that this bug became visible due to the recent __resched_legal() fix, which bug made most of our atomicity debugging checks ineffective. About half a dozen separate atomicity bugs triggered in -rt when i fixed the __resched_legal() bug, so i'd expect some more to trigger upstream too. Ingo > Subject: [patch] selinux: fix selinux_netlbl_inode_permission() locking From: Parag Warudkar <[EMAIL PROTECTED]> do not call a sleeping lock API in an RCU read section. lock_sock_nested can sleep, its BH counterpart doesn't. selinux_netlbl_inode_permission() needs to use the BH counterpart unconditionally. Compile tested. From: Ingo Molnar <[EMAIL PROTECTED]> added BH disabling, because this function can be called from non-atomic contexts too, so a naked bh_lock_sock() would be deadlock-prone. Boot-tested the resulting kernel. Signed-off-by: Parag Warudkar <[EMAIL PROTECTED]> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> --- security/selinux/ss/services.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) Index: linux/security/selinux/ss/services.c === --- linux.orig/security/selinux/ss/services.c +++ linux/security/selinux/ss/services.c @@ -2660,9 +2660,11 @@ int selinux_netlbl_inode_permission(stru rcu_read_unlock(); return 0; } - lock_sock(sock->sk); + local_bh_disable(); + bh_lock_sock_nested(sock->sk); rc = selinux_netlbl_socket_setsid(sock, sksec->sid); - release_sock(sock->sk); + bh_unlock_sock(sock->sk); + local_bh_enable(); rcu_read_unlock(); return rc; - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.20-rc3: known regressions with patches available (part 2)
This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19 with patches available If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: selinux networking: sleeping function called from invalid context References : http://lkml.org/lkml/2006/12/24/78 Submitter : Adam J. Richter <[EMAIL PROTECTED]> Caused-By : Paul Moore <[EMAIL PROTECTED]> Handled-By : Parag Warudkar <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2006/12/24/89 Status : patch available Subject: kernel panics on boot (libata-sff) References : http://lkml.org/lkml/2006/12/3/99 http://lkml.org/lkml/2006/12/14/153 http://lkml.org/lkml/2006/12/24/33 http://lkml.org/lkml/2007/1/1/84 Submitter : Alessandro Suardi <[EMAIL PROTECTED]> Theodore Tso <[EMAIL PROTECTED]> Caused-By : Alan Cox <[EMAIL PROTECTED]> commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f Handled-By : Alan Cox <[EMAIL PROTECTED]> Jeff Garzik <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/1/2/64 Status : patch available Subject: PCI_MULTITHREAD_PROBE breakage References : http://lkml.org/lkml/2006/12/12/21 Submitter : Ben Castricum <[EMAIL PROTECTED]> Caused-By : Greg Kroah-Hartman <[EMAIL PROTECTED]> commit 009af1ff78bfc30b9a27807dd0207fc32848218a Handled-By : Greg Kroah-Hartman <[EMAIL PROTECTED]> Status : patch available - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.20-rc3: known unfixed regressions
This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: kernel immediately reboots References : http://lkml.org/lkml/2007/1/2/15 Submitter : Steve Youngs <[EMAIL PROTECTED]> Status : unknown Subject: Acer Extensa 3002 WLMi: 'shutdown -h now' reboots the system References : http://lkml.org/lkml/2006/12/25/40 Submitter : Berthold Cogel <[EMAIL PROTECTED]> Status : unknown Subject: USB keyboard unresponsive after some time References : http://lkml.org/lkml/2006/12/25/35 http://lkml.org/lkml/2006/12/26/106 Submitter : Florin Iucha <[EMAIL PROTECTED]> Status : unknown Subject: BUG: scheduling while atomic References : http://lkml.org/lkml/2006/12/26/105 Submitter : Jon Smirl <[EMAIL PROTECTED]> Status : unknown Subject: SPARC64: Can't mount / References : http://lkml.org/lkml/2006/12/13/181 Submitter : Horst H. von Brand <[EMAIL PROTECTED]> Status : unknown Subject: ftp: get or put stops during file-transfer References : http://lkml.org/lkml/2006/12/16/174 Submitter : Komuro <[EMAIL PROTECTED]> Caused-By : YOSHIFUJI Hideaki <[EMAIL PROTECTED]> commit cfb6eeb4c860592edd123fdea908d23c6ad1c7dc Handled-By : YOSHIFUJI Hideaki <[EMAIL PROTECTED]> Status : problem is being debugged Subject: forcedeth.c 0.59: problem with sideband managment References : http://bugzilla.kernel.org/show_bug.cgi?id=7684 Submitter : Michael Reske <[EMAIL PROTECTED]> Handled-By : Ayaz Abdulla <[EMAIL PROTECTED]> Status : problem is being debugged Subject: x86_64 boot failure: "IO-APIC + timer doesn't work" References : http://lkml.org/lkml/2006/12/16/101 Submitter : Tobias Diedrich <[EMAIL PROTECTED]> Caused-By : Andi Kleen <[EMAIL PROTECTED]> commit b026872601976f666bae77b609dc490d1834bf77 Handled-By : Yinghai Lu <[EMAIL PROTECTED]> Eric W. Biederman <[EMAIL PROTECTED]> Status : problem is being debugged - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/6] sky2 driver update (v1.11)
On Mon, Jan 01, 2007 at 10:36:44 -0800, Stephen Hemminger wrote: > On Tue, 26 Dec 2006 16:44:24 -0500 > Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > Stephen Hemminger wrote: > > > Patches are in order of severity. 1-3 are bug fixes, 4 is a cleanup > > > of the power state code, and 5 adds wake on lan support. > > > > > > IMHO, it is bad security policy to allow wake on lan to enabled by > > > default. > > > The sky2 driver doesn't do WOL until enabled with ethtool. > > > > While in general I agree with you on the security principle, this seems > > like it might break working setups. > > > > WOL is a partnership between the motherboard and NIC. The motherboard > > must support WOL, or its useless. And since the motherboard must > > support WOL, it normally has an on/off switch in BIOS. > > > > As such, you're overriding the admin's chosen BIOS setting here. > > > > Jeff > > But there is no way to read the BIOS settings. > > If BIOS was being smart enough to actually, setup the chip, then I can > look at chip registers on startup and see if it is enabled there. Some computers even don't have such a BIOS settings (like my Mac mini). Btw., I just built 2.6.20-rc3 with patches 4 and 5 and wake on LAN now works. Thanks for your work. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/6] sky2 driver update (v1.11)
On Tue, 26 Dec 2006 16:44:24 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: > Stephen Hemminger wrote: > > Patches are in order of severity. 1-3 are bug fixes, 4 is a cleanup > > of the power state code, and 5 adds wake on lan support. > > > > IMHO, it is bad security policy to allow wake on lan to enabled by default. > > The sky2 driver doesn't do WOL until enabled with ethtool. > > While in general I agree with you on the security principle, this seems > like it might break working setups. > > WOL is a partnership between the motherboard and NIC. The motherboard > must support WOL, or its useless. And since the motherboard must > support WOL, it normally has an on/off switch in BIOS. > > As such, you're overriding the admin's chosen BIOS setting here. > > Jeff But there is no way to read the BIOS settings. If BIOS was being smart enough to actually, setup the chip, then I can look at chip registers on startup and see if it is enabled there. -- 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: Network card IRQ balancing with Intel 5000 series chipsets
With NAPI, if i have a few interupts it likely implies i have a huge network load (and therefore CPU use) and would be much more happier if you didnt start moving more interupt load to that already loaded CPU current irqbalance accounts for napi by using the number of packets as indicator for load, not the number of interrupts. (for network interrupts obviously) And hopefully some knowledge of NUMA so it doesn't "balance" the interrupts of a NIC to some far-off (topology-wise) CPU... rick jones - 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: Network card IRQ balancing with Intel 5000 series chipsets
The best way to achieve such balancing is to have the network card help and essentially be able to select the CPU to notify while at the same time considering: a) avoiding any packet reordering - which restricts a flow to be processed to a single CPU at least within a timeframe b) be per-CPU-load-aware - which means to busy out only CPUs which are less utilized Various such schemes have been discussed here but no vendor is making such nics today (search Daves Blog - he did discuss this at one point or other). I thought that Neterion were doing something along those lines with their Xframe II NICs - perhaps not CPU loading aware, but doing stuff to spread the work of different connections across the CPUs. I would add a: c) some knowledge of the CPU on which the thread accessing the socket for that "connection" will run. This could be as simple as the CPU on which the socket was last accessed. Having a _NIC_ know this sort of thing is somewhat difficult and expensive (perhaps too much so). If a NIC simply hashes the connection idendifiers you then have the issue of different connections, each "owned/accessed" by one thread, taking different paths through the system. No issues about reordering, but perhaps some on cache lines going hither and yon. The question boils down to - Should the application (via the scheduler) dictate where its connections are processed, or should the connections dictate where the application runs? rick jones - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
On Tuesday 02 January 2007 10:41, Sid Boyce wrote: > Same problem with 2.6.19-rc3. Do you mean 2.6.20-rc3 still does not work? What was the last kernel that worked properly with no cmdline parameters? > Apologies for the long spiel, if memory serves me correct, gzip'd > attachments are verboten. Bugzilla may be a good place to put more information. If the system fails in ACPI mode, but works in non-ACPI mode, then please file a bug here: http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI and attach the complete dmesg -s64000 for the last working, plus failing kernel -- along with /proc/interrupts for both, and a single copy of lspci -vv output. > openSUSE 10.2 > Network does not get configured with "acpi=noirq" or "acpi=off". Do you mean it does not work when running in ACPI mode, but it does work correctly if you boot with "acpi=noirq" or "acpi=off"? If so, please include the dmesg -s64000 and /proc/interrupts for the acpi=off case also. Nothing jumps out as incorrect with the ACPI IRQ routing below. Maybe somebody who knows about the tg3 can suggest what the error messages mean and if they are related to interrupt problems, or perhaps something else like IO resource issues? -Len > There may be something in dmesg that allows further analysis of the > problem. > 00:0a:e4:4e:a1:42 is the laptop MAC address. > 00:48:54:d0:22:f0 is the firewall box > 00:50:22:40:0F:D2 is a local box > Some things in dmesg which look decidedly strange when compared to what > is seen with 2.6.18.2-34, two mac addresses strung together with an > additional :08:00. I'm guessing here, this may be normal but I haven't > seen such before. > Linux version 2.6.20-rc1-git7-default ([EMAIL PROTECTED]) (gcc version 4.1.2 > 20061115 (prerelease) (SUSE Linux)) #4 SMP Wed Dec 20 01:17:23 GMT 2006 > Command line: root=/dev/hda1 vga=0x317resume=/dev/hda2 splash=silent 3 > BIOS-provided physical RAM map: > BIOS-e820: - 0009f800 (usable) > BIOS-e820: 0009f800 - 000a (reserved) > BIOS-e820: 000d8000 - 0010 (reserved) > BIOS-e820: 0010 - 1fef (usable) > BIOS-e820: 1fef - 1fefb000 (ACPI data) > BIOS-e820: 1fefb000 - 1ff0 (ACPI NVS) > BIOS-e820: 1ff0 - 2000 (reserved) > BIOS-e820: fffe - 0001 (reserved) > Entering add_active_range(0, 0, 159) 0 entries of 3200 used > Entering add_active_range(0, 256, 130800) 1 entries of 3200 used > end_pfn_map = 1048576 > DMI 2.3 present. > ACPI: RSDP (v000 PTLTD ) @ > 0x000f68c0 > ACPI: RSDT (v001 PTLTDRSDT 0x0604 LTP 0x) @ > 0x1fef5d48 > ACPI: FADT (v002 AMDK8 PTLTW0x0604 PTL_ 0x000f4240) @ > 0x1fefae56 > ACPI: SSDT (v001 PTLTD POWERNOW 0x0604 LTP 0x0001) @ > 0x1fefaeda > ACPI: MADT (v001 PTLTD APIC 0x0604 LTP 0x) @ > 0x1fefafb0 > ACPI: DSDT (v001 VIA PTL_ACPI 0x0604 MSFT 0x010e) @ > 0x > Scanning NUMA topology in Northbridge 24 > Number of nodes 1 > Node 0 MemBase Limit 1fef > Entering add_active_range(0, 0, 159) 0 entries of 3200 used > Entering add_active_range(0, 256, 130800) 1 entries of 3200 used > NUMA: Using 63 for the hash shift. > Using node hash shift of 63 > Bootmem setup node 0 -1fef > Zone PFN ranges: > DMA 0 -> 4096 > DMA324096 -> 1048576 > Normal1048576 -> 1048576 > early_node_map[2] active PFN ranges > 0:0 -> 159 > 0: 256 -> 130800 > On node 0 totalpages: 130703 > DMA zone: 56 pages used for memmap > DMA zone: 1183 pages reserved > DMA zone: 2760 pages, LIFO batch:0 > DMA32 zone: 1732 pages used for memmap > DMA32 zone: 124972 pages, LIFO batch:31 > Normal zone: 0 pages used for memmap > ACPI: PM-Timer IO Port: 0x4008 > ACPI: Local APIC address 0xfee0 > ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) > Processor #0 (Bootup-CPU) > ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) > ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) > IOAPIC[0]: apic_id 1, address 0xfec0, GSI 0-23 > ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) > ACPI: IRQ0 used by override. > ACPI: IRQ2 used by override. > ACPI: IRQ9 used by override. > Setting APIC routing to physical flat > Using ACPI (MADT) for SMP configuration information > Nosave address range: 0009f000 - 000a > Nosave address range: 000a - 000d8000 > Nosave address range: 000d8000 - 0010 > Allocating PCI resources starting at 3000 (gap: 2000:dffe) > SMP: Allowing 1 CPUs, 0 hotplug CPUs > PERCPU: Allocating 49664 bytes of per cpu data > Built 1 zonelists. Total pages: 127732 > Kernel command line: root=/dev/hda1 vga=0x317resume=/dev/hda2 > splash=sil
Re: [PATCH] d80211: Fix inconsistent sta_lock usage
On Tue, Jan 02, 2007 at 04:30:41PM +0100, Ivo Van Doorn wrote:
> +static inline void __bss_tim_set(struct ieee80211_local *local,
> + struct ieee80211_if_ap *bss, int aid)
> +{
> + bss->tim[(aid)/8] |= 1<<((aid) % 8);
> +}
This really screams to be converted to __set_bit. Also the local
argument is entirely unused. I'd probaby not even add a helper for
this but just opencode it as:
__set_bit(&bss->time, aid);
> +static inline void __bss_tim_clear(struct ieee80211_local *local,
> +struct ieee80211_if_ap *bss, int aid)
> +{
> + bss->tim[(aid)/8] &= !(1<<((aid) % 8));
Similarly this should just be __clear_bit
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
Same problem with 2.6.19-rc3. Apologies for the long spiel, if memory serves me correct, gzip'd attachments are verboten. openSUSE 10.2 Network does not get configured with "acpi=noirq" or "acpi=off". There may be something in dmesg that allows further analysis of the problem. 00:0a:e4:4e:a1:42 is the laptop MAC address. 00:48:54:d0:22:f0 is the firewall box 00:50:22:40:0F:D2 is a local box Some things in dmesg which look decidedly strange when compared to what is seen with 2.6.18.2-34, two mac addresses strung together with an additional :08:00. I'm guessing here, this may be normal but I haven't seen such before. Linux version 2.6.20-rc1-git7-default ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #4 SMP Wed Dec 20 01:17:23 GMT 2006 Command line: root=/dev/hda1 vga=0x317resume=/dev/hda2 splash=silent 3 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000d8000 - 0010 (reserved) BIOS-e820: 0010 - 1fef (usable) BIOS-e820: 1fef - 1fefb000 (ACPI data) BIOS-e820: 1fefb000 - 1ff0 (ACPI NVS) BIOS-e820: 1ff0 - 2000 (reserved) BIOS-e820: fffe - 0001 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 130800) 1 entries of 3200 used end_pfn_map = 1048576 DMI 2.3 present. ACPI: RSDP (v000 PTLTD ) @ 0x000f68c0 ACPI: RSDT (v001 PTLTDRSDT 0x0604 LTP 0x) @ 0x1fef5d48 ACPI: FADT (v002 AMDK8 PTLTW0x0604 PTL_ 0x000f4240) @ 0x1fefae56 ACPI: SSDT (v001 PTLTD POWERNOW 0x0604 LTP 0x0001) @ 0x1fefaeda ACPI: MADT (v001 PTLTD APIC 0x0604 LTP 0x) @ 0x1fefafb0 ACPI: DSDT (v001 VIA PTL_ACPI 0x0604 MSFT 0x010e) @ 0x Scanning NUMA topology in Northbridge 24 Number of nodes 1 Node 0 MemBase Limit 1fef Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 130800) 1 entries of 3200 used NUMA: Using 63 for the hash shift. Using node hash shift of 63 Bootmem setup node 0 -1fef Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1048576 early_node_map[2] active PFN ranges 0:0 -> 159 0: 256 -> 130800 On node 0 totalpages: 130703 DMA zone: 56 pages used for memmap DMA zone: 1183 pages reserved DMA zone: 2760 pages, LIFO batch:0 DMA32 zone: 1732 pages used for memmap DMA32 zone: 124972 pages, LIFO batch:31 Normal zone: 0 pages used for memmap ACPI: PM-Timer IO Port: 0x4008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Setting APIC routing to physical flat Using ACPI (MADT) for SMP configuration information Nosave address range: 0009f000 - 000a Nosave address range: 000a - 000d8000 Nosave address range: 000d8000 - 0010 Allocating PCI resources starting at 3000 (gap: 2000:dffe) SMP: Allowing 1 CPUs, 0 hotplug CPUs PERCPU: Allocating 49664 bytes of per cpu data Built 1 zonelists. Total pages: 127732 Kernel command line: root=/dev/hda1 vga=0x317resume=/dev/hda2 splash=silent 3 Initializing CPU#0 PID hash table entries: 2048 (order: 11, 16384 bytes) Console: colour dummy device 80x25 Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) Checking aperture... CPU 0: aperture @ e000 size 256 MB Memory: 507156k/523200k available (1948k kernel code, 15656k reserved, 950k data, 324k init) Calibrating delay using timer specific routine.. 3591.92 BogoMIPS (lpj=1795961) Security Framework v1.0.0 initialized Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU 0/0 -> Node 0 SMP alternatives: switching to UP code Freeing SMP alternatives: 28k freed ACPI: Core revision 20060707 Using local APIC timer interrupts. result 12464666 Detected 12.464 MHz APIC timer. Brought up 1 CPUs testing NMI watchdog ... OK. time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer. time.c: Detected 1794.911 MHz processor. NET: Registered protocol family 16 ACPI: bus type pci registered PCI: Using configuration type 1 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [
Re: [PATCH] d80211: Reinit keys on mode change
On 1/1/07, Jan Kiszka <[EMAIL PROTECTED]> wrote: Switching the interface mode with some encryption keys set and then later touching any key, triggers an oops because ieee80211_if_reinit fails to NULL'ify the related pointers after free'ing the key on mode change. Long explanation, simple fix below. Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]> [Sorry, yet another rt2x00 CVS patch...] To make it easier for everybody, here is the same patch only this time applied to the dscape git tree. ;) Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]> Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]> --- diff --git a/net/d80211/ieee80211_iface.c b/net/d80211/ieee80211_iface.c index 3e9d531..7d4ec56 100644 --- a/net/d80211/ieee80211_iface.c +++ b/net/d80211/ieee80211_iface.c @@ -229,6 +229,7 @@ void ieee80211_if_reinit(struct net_device *dev) local->keys[i], 0); #endif ieee80211_key_free(sdata->keys[i]); + sdata->keys[i] = NULL; } /* Shouldn't be necessary but won't hurt */ - 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: Fix inconsistent sta_lock usage
On 1/1/07, Jan Kiszka <[EMAIL PROTECTED]> wrote:
Hacking a bit on rt2x00 to make it work in master and ad-hoc mode, lockdep
popped up on some hostapd ioctls, pointing out remaining inconsistencies
related to sta_lock:
1. sta_lock holders must always be protected against softirq
2. bss_tim_set/clear must not be called with sta_lock held, rather an
unprotected variant
3. ieee80211_ioctl_remove_sta is not already holding the lock when calling
sta_info_free
As I was not sure if sta_info_remove_aid_ptr needs lock protection or
not, I played safe and moved it always under the lock. Please correct me
if this is overkill.
Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]>
[Sorry, patch is against rt2x00 CVS. I'm lacking time and bandwidth to pull
the d80211 git repos and rebase.]
To make it easier for everybody, here is the same patch
only this time applied to the dscape git tree. ;)
Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]>
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
---
diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h
index ef303da..b132ae0 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
@@ -558,20 +558,32 @@ struct sta_attribute {
ssize_t (*store)(struct sta_info *, const char *buf, size_t count);
};
+static inline void __bss_tim_set(struct ieee80211_local *local,
+struct ieee80211_if_ap *bss, int aid)
+{
+ bss->tim[(aid)/8] |= 1<<((aid) % 8);
+}
+
static inline void bss_tim_set(struct ieee80211_local *local,
struct ieee80211_if_ap *bss, int aid)
{
- spin_lock(&local->sta_lock);
- bss->tim[(aid)/8] |= 1<<((aid) % 8);
- spin_unlock(&local->sta_lock);
+ spin_lock_bh(&local->sta_lock);
+ __bss_tim_set(local, bss, aid);
+ spin_unlock_bh(&local->sta_lock);
+}
+
+static inline void __bss_tim_clear(struct ieee80211_local *local,
+ struct ieee80211_if_ap *bss, int aid)
+{
+ bss->tim[(aid)/8] &= !(1<<((aid) % 8));
}
static inline void bss_tim_clear(struct ieee80211_local *local,
struct ieee80211_if_ap *bss, int aid)
{
- spin_lock(&local->sta_lock);
- bss->tim[(aid)/8] &= !(1<<((aid) % 8));
- spin_unlock(&local->sta_lock);
+ spin_lock_bh(&local->sta_lock);
+ __bss_tim_clear(local, bss, aid);
+ spin_unlock_bh(&local->sta_lock);
}
/* ieee80211.c */
diff --git a/net/d80211/ieee80211_ioctl.c b/net/d80211/ieee80211_ioctl.c
index c74b431..1363a01 100644
--- a/net/d80211/ieee80211_ioctl.c
+++ b/net/d80211/ieee80211_ioctl.c
@@ -285,7 +285,9 @@ static int ieee80211_ioctl_add_sta(struct net_device *dev,
if (sta->dev != dev) {
/* Binding STA to a new interface, so remove all references to
* the old BSS. */
+ spin_lock_bh(&local->sta_lock);
sta_info_remove_aid_ptr(sta);
+ spin_unlock_bh(&local->sta_lock);
}
/* TODO
@@ -359,7 +361,7 @@ static int ieee80211_ioctl_remove_sta(struct
net_device *dev,
sta = sta_info_get(local, param->sta_addr);
if (sta) {
sta_info_put(sta);
- sta_info_free(sta, 1);
+ sta_info_free(sta, 0);
}
return sta ? 0 : -ENOENT;
diff --git a/net/d80211/sta_info.c b/net/d80211/sta_info.c
index 0c42ae8..e120a4f 100644
--- a/net/d80211/sta_info.c
+++ b/net/d80211/sta_info.c
@@ -439,7 +439,7 @@ void sta_info_remove_aid_ptr(struct sta_info *sta)
sdata->local->ops->set_tim(local_to_hw(sdata->local),
sta->aid, 0);
if (sdata->bss)
- bss_tim_clear(sdata->local, sdata->bss, sta->aid);
+ __bss_tim_clear(sdata->local, sdata->bss, sta->aid);
}
-
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] xfrm_user: avoid pointless void ** casts
All ->doit handlers want a struct rtattr **, so pass down the right
type.
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Index: linux-2.6/net/xfrm/xfrm_user.c
===
--- linux-2.6.orig/net/xfrm/xfrm_user.c 2006-12-12 11:30:55.0 +0100
+++ linux-2.6/net/xfrm/xfrm_user.c 2007-01-02 15:35:31.0 +0100
@@ -434,18 +434,19 @@
return NULL;
}
-static int xfrm_add_sa(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma)
+static int xfrm_add_sa(struct sk_buff *skb, struct nlmsghdr *nlh,
+ struct rtattr **xfrma)
{
struct xfrm_usersa_info *p = NLMSG_DATA(nlh);
struct xfrm_state *x;
int err;
struct km_event c;
- err = verify_newsa_info(p, (struct rtattr **)xfrma);
+ err = verify_newsa_info(p, xfrma);
if (err)
return err;
- x = xfrm_state_construct(p, (struct rtattr **)xfrma, &err);
+ x = xfrm_state_construct(p, xfrma, &err);
if (!x)
return err;
@@ -507,14 +508,15 @@
return x;
}
-static int xfrm_del_sa(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma)
+static int xfrm_del_sa(struct sk_buff *skb, struct nlmsghdr *nlh,
+ struct rtattr **xfrma)
{
struct xfrm_state *x;
int err = -ESRCH;
struct km_event c;
struct xfrm_usersa_id *p = NLMSG_DATA(nlh);
- x = xfrm_user_state_lookup(p, (struct rtattr **)xfrma, &err);
+ x = xfrm_user_state_lookup(p, xfrma, &err);
if (x == NULL)
return err;
@@ -672,14 +674,15 @@
return skb;
}
-static int xfrm_get_sa(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma)
+static int xfrm_get_sa(struct sk_buff *skb, struct nlmsghdr *nlh,
+ struct rtattr **xfrma)
{
struct xfrm_usersa_id *p = NLMSG_DATA(nlh);
struct xfrm_state *x;
struct sk_buff *resp_skb;
int err = -ESRCH;
- x = xfrm_user_state_lookup(p, (struct rtattr **)xfrma, &err);
+ x = xfrm_user_state_lookup(p, xfrma, &err);
if (x == NULL)
goto out_noput;
@@ -718,7 +721,8 @@
return 0;
}
-static int xfrm_alloc_userspi(struct sk_buff *skb, struct nlmsghdr *nlh, void
**xfrma)
+static int xfrm_alloc_userspi(struct sk_buff *skb, struct nlmsghdr *nlh,
+ struct rtattr **xfrma)
{
struct xfrm_state *x;
struct xfrm_userspi_info *p;
@@ -1013,7 +1017,8 @@
return NULL;
}
-static int xfrm_add_policy(struct sk_buff *skb, struct nlmsghdr *nlh, void
**xfrma)
+static int xfrm_add_policy(struct sk_buff *skb, struct nlmsghdr *nlh,
+ struct rtattr **xfrma)
{
struct xfrm_userpolicy_info *p = NLMSG_DATA(nlh);
struct xfrm_policy *xp;
@@ -1024,11 +1029,11 @@
err = verify_newpolicy_info(p);
if (err)
return err;
- err = verify_sec_ctx_len((struct rtattr **)xfrma);
+ err = verify_sec_ctx_len(xfrma);
if (err)
return err;
- xp = xfrm_policy_construct(p, (struct rtattr **)xfrma, &err);
+ xp = xfrm_policy_construct(p, xfrma, &err);
if (!xp)
return err;
@@ -1227,7 +1232,8 @@
return skb;
}
-static int xfrm_get_policy(struct sk_buff *skb, struct nlmsghdr *nlh, void
**xfrma)
+static int xfrm_get_policy(struct sk_buff *skb, struct nlmsghdr *nlh,
+ struct rtattr **xfrma)
{
struct xfrm_policy *xp;
struct xfrm_userpolicy_id *p;
@@ -1239,7 +1245,7 @@
p = NLMSG_DATA(nlh);
delete = nlh->nlmsg_type == XFRM_MSG_DELPOLICY;
- err = copy_from_user_policy_type(&type, (struct rtattr **)xfrma);
+ err = copy_from_user_policy_type(&type, xfrma);
if (err)
return err;
@@ -1250,11 +1256,10 @@
if (p->index)
xp = xfrm_policy_byid(type, p->dir, p->index, delete);
else {
- struct rtattr **rtattrs = (struct rtattr **)xfrma;
- struct rtattr *rt = rtattrs[XFRMA_SEC_CTX-1];
+ struct rtattr *rt = xfrma[XFRMA_SEC_CTX-1];
struct xfrm_policy tmp;
- err = verify_sec_ctx_len(rtattrs);
+ err = verify_sec_ctx_len(xfrma);
if (err)
return err;
@@ -1302,7 +1307,8 @@
return err;
}
-static int xfrm_flush_sa(struct sk_buff *skb, struct nlmsghdr *nlh, void
**xfrma)
+static int xfrm_flush_sa(struct sk_buff *skb, struct nlmsghdr *nlh,
+ struct rtattr **xfrma)
{
struct km_event c;
struct xfrm_usersa_flush *p = NLMSG_DATA(nlh);
@@ -1367,7 +1373,8 @@
return -1;
}
-static int xfrm_get_ae(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma)
+static int xfrm_get_ae(struct sk_buff *skb, struct nlmsghdr *nlh,
+ struct rtattr **xfrma)
{
struct xfrm_state *x;
struct sk_buff *r_
d80211: How does TX flow control work?
Hi, can someone explain how TX flow control in d80211 is supposed to work? I failed to understand the full design so far. What I (think to) understand is that a low-level drivers call ieee80211_stop_queue() if they run out of buffers. That flips a per-queue bit (IEEE80211_LINK_STATE_XOFF), prevents that any further frame is passed to the low-level TX routine, and can cause that up to *one* packet per queue is stored in ieee80211_local::pending_packets[queue]. But it looks to me like nothing prevents ieee80211_tx() being invoked even in case that there is already some stuff in that single-packet storage. That in turn triggers WARN_ONs in ieee80211_tx() under high load for me (with rt2500usb). And it should also cause orphaned skbs because the storage is overwritten in that case. Either I'm blind or something is fishy... Jan signature.asc Description: OpenPGP digital signature
[PATCH] net: af_netlink module_put cleanup
Hello,
This patch removes redundant argument check for module_put().
Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
net/netlink/af_netlink.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff -upr linux-2.6.20-rc2-mm1-a/net/netlink/af_netlink.c
linux-2.6.20-rc2-mm1-b/net/netlink/af_netlink.c
--- linux-2.6.20-rc2-mm1-a/net/netlink/af_netlink.c 2006-12-24
05:00:32.0 +0100
+++ linux-2.6.20-rc2-mm1-b/net/netlink/af_netlink.c 2007-01-02
02:23:02.0 +0100
@@ -472,8 +472,7 @@ static int netlink_release(struct socket
NETLINK_URELEASE, &n);
}
- if (nlk->module)
- module_put(nlk->module);
+ module_put(nlk->module);
netlink_table_grab();
if (nlk->flags & NETLINK_KERNEL_SOCKET) {
--
Regards,
Mariusz Kozlowski
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] net/irda/: proper prototypes
On Tue, Jan 02, 2007 at 12:39:53AM -0800, David Miller wrote: > From: Adrian Bunk <[EMAIL PROTECTED]> > Date: Mon, 18 Dec 2006 04:46:26 +0100 > > > This patch adds proper prototypes for some functions in > > include/net/irda/irda.h > > > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > ... > > +struct net_device; > > +struct packet_type; > > + > > +void irda_proc_register(void); > > +void irda_proc_unregister(void); > > + > > +int irda_sysctl_register(void); > > +void irda_sysctl_unregister(void); > > + > > +int irsock_init(void); > > +void irsock_cleanup(void); > > + > > +int irlap_driver_rcv(struct sk_buff *skb, struct net_device *dev, > > +struct packet_type *ptype, struct net_device *orig_dev); > > Remind me why you remove the "extern" from "external" function > declarations all the time? It's shorter, letting more contents fit into one line. > I don't like it, even if it's "correct", because it is inconsistent > with what we do in the entire rest of the networking code. Good point. Is it OK to slowly starting converting them or do you want them to stay? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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] net: ifb error path loop fix
Hello David,
> One could argue from a defensive programming perspective that
> this bug comes from the fact that the ifb_init_one() loop
> advances state before checking for errors ('i' is advanced before
> the 'err' check due to the loop construct), and that's why the
> error recovery code had to be coded specially :-)
Now when I look at it I might be wrong and it is not a bug at all.
It's just coded in weird way. Anyway isn't there kfree(ifbs) missing
on error path?
The patch below should clear things a bit (against plain 2.6.20-rc2-mm1).
Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
drivers/net/ifb.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
--- linux-2.6.20-rc2-mm1-a/drivers/net/ifb.c2006-12-24 05:00:32.0
+0100
+++ linux-2.6.20-rc2-mm1-b/drivers/net/ifb.c2007-01-02 11:35:48.0
+0100
@@ -264,18 +264,22 @@ static void ifb_free_one(int index)
static int __init ifb_init_module(void)
{
- int i, err = 0;
+ int i, err;
+
ifbs = kmalloc(numifbs * sizeof(void *), GFP_KERNEL);
if (!ifbs)
return -ENOMEM;
- for (i = 0; i < numifbs && !err; i++)
+ for (i = 0; i < numifbs; i++) {
err = ifb_init_one(i);
- if (err) {
- i--;
- while (--i >= 0)
- ifb_free_one(i);
+ if (err)
+ goto err;
}
+ return 0;
+err:
+ while (i--)
+ ifb_free_one(i);
+ kfree(ifbs);
return err;
}
--
Regards,
Mariusz Kozlowski
-
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] net: ifb error path loop fix
On 02-01-2007 08:51, David Miller wrote:
> From: Mariusz Kozlowski <[EMAIL PROTECTED]>
> Date: Tue, 2 Jan 2007 00:55:51 +0100
>
>> On error we should start freeing resources at [i-1] not [i-2].
>>
>> Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
>
> Patch applied, thanks Mariusz.
>
>> diff -upr linux-2.6.20-rc2-mm1-a/drivers/net/ifb.c
>> linux-2.6.20-rc2-mm1-b/drivers/net/ifb.c
>> --- linux-2.6.20-rc2-mm1-a/drivers/net/ifb.c 2006-12-24 05:00:32.0
>> +0100
>> +++ linux-2.6.20-rc2-mm1-b/drivers/net/ifb.c 2007-01-02 00:25:34.0
>> +0100
>> @@ -271,8 +271,7 @@ static int __init ifb_init_module(void)
>> for (i = 0; i < numifbs && !err; i++)
>> err = ifb_init_one(i);
>> if (err) {
>> -i--;
>> -while (--i >= 0)
>> +while (i--)
>> ifb_free_one(i);
>> }
After this patch:
for (i = 0 ...); // i == 0
err = ifb_init_one(i); // err != 0
i++; // i == 1
for (... !err ...); // break
if (err) {
while (i--) // i == 1 (when testing)
ifb_free_one(i); // i == 0 (not initialized)
}
Btw. wasn't this place patched yet?
Regards,
Jarek P.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: soft lockup detected on CPU#0! (2.6.18.2 plus hacks)
On Tue, Jan 02, 2007 at 09:23:02AM +0100, Jarek Poplawski wrote: > On Tue, Jan 02, 2007 at 08:39:09AM +0100, Jarek Poplawski wrote: > ... > > The main thing is the possibility of processing > > skb with not entirely open source dev which isn't > > expected (and checked) by receive functions. > > I think the easiest way to convince yourself is > > to add temporarily IFF_UP flag checking with > > dropping at the beginning of netif_receive_skb and > > __vlan_hwaccel_rx. ... and vlan_skb_recv also. Jarek P. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: selinux networking: sleeping functin called from invalid context in 2.6.20-rc[12]
On Sun, Dec 24, 2006 at 04:25:11PM -0800, Andrew Morton wrote:
> On Mon, 25 Dec 2006 05:21:24 +0800
> "Adam J. Richter" <[EMAIL PROTECTED]> wrote:
>
>> Under 2.6.20-rc1 and 2.6.20-rc2, I get the following complaint
>> for several network programs running on my system:
>>
>> [ 156.381868] BUG: sleeping function called from invalid context at
>> net/core/sock.c:1523
[...]
> There's a glaring bug in selinux_netlbl_inode_permission() - taking
> lock_sock() inside rcu_read_lock().
>
> I would again draw attention to Documentation/SubmitChecklist. In
> particular please always always always enable all kernel debugging options
> when developing and testing new kernel code. And everything else in that
> file, too.
>
>
I have not yet performed the 21 steps of
linux-2.6.20-rc3/Documentation/SubmitChecklist, which I think is a
great objectives list for future automation or some kind of community
web site. I hope to find time to make progress through that
checklist, but, in the meantime, I think the world may nevertheless be
infinitesmally better off if I post the patch that I'm currently
using that seems to fix the problem, seeing as how rc3 has passed
with no fix incorporated.
I think the intent of the offending code was to avoid doing
a lock_sock() in a presumably common case where there was no need to
take the lock. So, I have kept the presumably fast test to exit
early.
When it turns out to be necessary to take lock_sock(), RCU is
unlocked, then lock_sock is taken, the RCU is locked again, and
the test is repeated.
If I am wrong about lock_sock being expensive, I can
delete the lines that do the early return.
By the way, in a change not included in this patch,
I also tried consolidating the RCU locking in this file into a macro
IF_NLBL_REQUIRE(sksec, action), where "action" is the code
fragment to be executed with rcu_read_lock() held, although this
required splitting a couple of functions in half.
Anyhow, here is my current patch as MIME attachment.
Comments and labor in getting it through SubmitChecklist would
both be welcome.
Adam Richter
--- linux-2.6.20-rc3/security/selinux/ss/services.c 2007-01-02
01:47:40.0 +0800
+++ linux/security/selinux/ss/services.c2007-01-02 15:36:30.0
+0800
@@ -2658,14 +2658,22 @@
rcu_read_lock();
if (sksec->nlbl_state != NLBL_REQUIRE) {
rcu_read_unlock();
return 0;
}
+ rcu_read_unlock();
+
+
+ rc = 0;
lock_sock(sock->sk);
- rc = selinux_netlbl_socket_setsid(sock, sksec->sid);
- release_sock(sock->sk);
+ rcu_read_lock();
+
+ if (sksec->nlbl_state == NLBL_REQUIRE)
+ rc = selinux_netlbl_socket_setsid(sock, sksec->sid);
+
rcu_read_unlock();
+ release_sock(sock->sk);
return rc;
}
/**
Re: [PATCH] xt_hashlimit.c: fix typo
From: Alexey Dobriyan <[EMAIL PROTECTED]> Date: Tue, 19 Dec 2006 18:57:33 +0300 > Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> Applied, thanks Alexey. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] net/irda/: proper prototypes
From: Adrian Bunk <[EMAIL PROTECTED]> Date: Mon, 18 Dec 2006 04:46:26 +0100 > This patch adds proper prototypes for some functions in > include/net/irda/irda.h > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> ... > +struct net_device; > +struct packet_type; > + > +void irda_proc_register(void); > +void irda_proc_unregister(void); > + > +int irda_sysctl_register(void); > +void irda_sysctl_unregister(void); > + > +int irsock_init(void); > +void irsock_cleanup(void); > + > +int irlap_driver_rcv(struct sk_buff *skb, struct net_device *dev, > + struct packet_type *ptype, struct net_device *orig_dev); Remind me why you remove the "extern" from "external" function declarations all the time? I don't like it, even if it's "correct", because it is inconsistent with what we do in the entire rest of the networking code. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [IPVS] replace if .. goto with while
From: Horms <[EMAIL PROTECTED]> Date: Mon, 18 Dec 2006 12:11:11 +0900 > I guess that this code used to be more complex, but replacing > the goto with a while seems to make things a bit more readable. > Or in other words, two fairly gratuitous goto are removed. > > On a related note, I wonder if there should be a limit to how > many times it tries. > > Signed-Off-By: Simon Horman <[EMAIL PROTECTED]> Yes, there should be, something like a limit of one. :-) There is no reason to loop on something like this, just return a failure immediately if creating the kernel thread fails. As a side note, if it's easy you might want to convert this over the the include/linux/kthread.h interfaces. I just did this for pktgen tonight and it cleaned a lot of stuff up. - 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: BUG: soft lockup detected on CPU#0! (2.6.18.2 plus hacks)
On Tue, Jan 02, 2007 at 08:39:09AM +0100, Jarek Poplawski wrote: ... > It is hard to say what kind of bug to expect > because at the same time other net_rx_action > with the same vlan dev could take place on > other processor and this inetdev_init could > do more. Sorry! inetdev_init couldn't do more because of rtnl lock but anyway the rest should be valid: > The main thing is the possibility of processing > skb with not entirely open source dev which isn't > expected (and checked) by receive functions. > I think the easiest way to convince yourself is > to add temporarily IFF_UP flag checking with > dropping at the beginning of netif_receive_skb and > __vlan_hwaccel_rx. Jarek P. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
